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Executive Summary 

This deliverable describes the final form of the SDN-microSENSE Risk Assessment Framework (S-RAF). 
S-RAF differentiates from other risk assessment tools and acts as a complementary tool for the security 
of EPES infrastructure. More specifically, the following four are the main key points of differentiation 
between the adoption of S-RAF methodology and other risk assessment solutions: a) the cumulative 
risk assessment, b) the calculation methodology, c) the EPES-focused risk assessment and d) the deep 
insights on the security of EPES. 


S-RAF assesses the level of risk in all the involved EPES devices and systems by analysing a) current 
smart & loT devices, b) legacy SCADA & ICS devices, c) smart meters d) other software/hardware 
devices connected to EPES network and e) all the energy-related personnel and stakeholders (energy 
operators, consumers, prosumers, energy utilities, energy generators, energy actors & agents and 
energy retailers). S-RAF considers all the aforementioned assets and utilises the models produced from 
task T3.2, the output of honeypots developed in task T3.3 and the including readiness results acquired 
from T3.4, to provide a more holistic approach. 


Due to the distributed nature of the decentralised energy system, S-RAF takes into account the 
collaborative aspects needed to involve all stakeholders of the energy components, making the 
calculation of the cumulative risk of paramount importance. In other words, S-RAF cumulative risk 
assessment approach enables one to perceive the security state at the level of mission-critical assets 
that belong either in the same business workflow, or in the same physical (or virtual) networks. 


In addition, S-RAF extends UBITECH’s OLISTIC Enterprise Risk Management Suite. In the context of 
SDN-microSENSE, several updates have been performed to address the need for a collaborative risk 
assessment framework for EPES compared with OLISTIC. These updates can be summarised as the 
following eight: 


Usage of updated model that supports EPES 

Collaborative Risk Assessment with the cumulative RA 

Connecting with AIDB for EPES asset retrieval 

Connection with eVul for automated analysis of vulnerabilities in the EPES environment 

Extending OLISTIC model and components for retrieving alerts from XL-SIEM 

Providing Incidents based on the Risk Assessment as output to SDN-SELF and ARIEC 

components of SDN-microSENSE 

7. Integrating Apache Kafka as message queue that can be used by both internal and external 
components 

8. Transform data to MISP format 


9v ur dg m b 
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1 Introduction 

Risk assessment is of paramount importance for the efficient operation of Information and 
Communications Technology (ICT) deployments and hence for the EPES field. The SDN-microSENSE 
Risk Assessment Framevvork (S-RAF) component is tailored to the security requirements of EPES and 
the requirements defined in D2.2 [1], while it takes into account the collaborative aspects needed to 
involve all stakeholders of the energy components. S-RAF provides both the individual and cumulative 
risks in alignment with the proposed Energy Chain Risk Assessment (ECRA) Methodology. 


1.1 Purpose of the Document 

The main purpose of this deliverable is to document the results of the collaborative risk assessment 
(RA) Framework for energy chain S-RAF. As this is a public document, special care has been taken in 
order to handle privacy restrictions of the work performed in the scope of WP3. 


1.2 Structure of the Document 

The rest of the document is organised as follows. In Chapter 2, we describe the background of RA in 
EPES, by examining existing Risk Assessment tools and presenting the methodology of S-RAF. In 
Chapter 3, we describe the architecture of S-RAF, while Chapter 4 provides implementation details. 
Chapter 5 includes installation and usage instructions. Finally, Chapter 6 concludes the deliverable. 


1.3 Methodology 

Both for the implementation of S-RAF and the writing of this deliverable we have mainly relied on the 
work performed on tasks T3.1 and T3.2 that described the RA in the scope of EPES, and the overall 
platform architecture defined in WP2. Based on the requirements and the design aspects of these 
deliverables, the OLISTIC RA engine of UBITECH has been extended to provide the needed 
functionality. In addition, in order to ensure that the developed solution conforms to SDN-microSENSE 
use case needs, we also proceeded with the organisation of preliminary workshops with the use case 
leaders. 


1.4 Relation to other Deliverables and Work Packages 

Deliverables D3.1 [2] and D3.2 [3] served as the basis to the D3.5 SDN-microSENSE Risk Assessment 
Framework. D3.2 [3] considers the user security and privacy requirements described in D2.2 [1], the 
overall SDN-microSENSE architecture analysed in D2.3 [4] and the Risk Assessment Methodology of 
Energy Chain described in D3.1 [2]. Figure 1 depicts the dependencies of the deliverable to the other 
deliverables and Work Packages (WPs). 
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Figure 1: Deliverable D3.5 relationship within the SDN-microSENSE project 
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2 SDN-microSENSE Risk Assessment Framework as part of the Risk 


Assessment Market 


Risk management is the process of identifying, analysing and then responding to any risk that arises 
over the life cycle of any business operation and can potentially harm the output of that operation and 
any other related operation. Risk management isn't reactive only; it should be part of the planning 
process to figure out risk that might happen in the business operation and how to control that risk if it 
in fact occurs. 


A risk is anything that could potentially impact timeline, performance or budget. Risks are 
potentialities, and in a risk management context, if they become realities, they then become classified 
as "issues" that must be addressed. So, risk management then, is the process of identifying, 
categorising, prioritising and planning for risks before they become issues. 


While risk management processes and searching activities are taking place at the development stage, 
there is another metric which calculates the same concept described above and is called risk 
assessment. Risk assessment is operating while the business is already in place and the development 
phase has been completed. There are multiple risk assessment metrics which can be calculated, 
however for the scope of the SDN-microSENSE project our main concern is cyber security risk 
assessment and the harm of the EPES infrastructure concerning the cyber security risk. 


Fortunately, there are several platforms that gather third-party cyber risk data and provide a risk score 
or security rating for companies. The information gathering is done by a method called "passive scan" 
where non-intrusive methods are used and company assets remain untouched. It is basically a hacker's 
view of the third-parties external cyber risk. The open-source intelligence data is collected from many 
feeds such as reputation services, hacker sites/forums, vulnerability databases, Internet-wide 
scanners, social media, paste sites, black markets, underground forums, etc. Information gathering 
should be done for the company of interest and any related third-party company. 


2.1 Risk Assessment Methods/Tools 
The top players that provide such cyber risk scoring through passive scanning are presented below: 


e |BitSight [5], provides a security rating for an organization which lies between 250 to 900. This 
number is characterized by the company more like an insight into a hacker's point of view on 
an organization's IT security posture. 

e NormShield [6], provides different kind of metrics. It provides a security metric which states 
the organization’s cyber security readiness that lies between A to F. Moreover, it provides a 
metric for the security controls that are in place from 0 to 100 and also a financial metric which 
indicates the financial loss in monetary amount. 

e Security Scorecard [7], provides APT security risk assessment and protection. It uses data 
gleaned from traffic to/from an organization, as well as other publicly accessible data to build 
security ratings for evaluating vendors and partners and pricing cyber risk insurance policies, 
among other use cases. The platform also monitors so-called "hacker chatter", social 
networks, and public data breach feeds for indicators of compromise. Furthermore, they 
contain and provide as a service a threat database with their security data collected from all 
the above information. Security Scorecard provides A to F and 0 to 100 security rating system. 
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e UpGuard [8], provides a metric which is called CSTAR score. This score is between 0 and 950 
and takes into consideration not only security but compliance and integrity as vvell. It helps to 
identify and quantify the risk but also make the correct business decisions. Finally, it provides 
metrics that will help the organization identify their position compared to other organizations 
of the same industry. 

e MRiskrecon [9], makes it easy to gain deep, risk contextualized insight into the cybersecurity risk 
performance ofall third-parties by continuously monitoring across 11 security domains and 41 
security criteria. It distils its assessment criteria into a simple score from 0-10. 


They all provide risk scores or security ratings for any company. This type of cyber risk assessment can 
be used for suppliers, joint-ventures, target acquisitions, franchisees, cyber insurance customers, etc. 


Since the methodology and data resources are similar, the differentiating factors are data quality, 
technical depth, reliability (true positive), coverage (true negative), usability and reporting capabilities. 
The ideal scorecard should sufficiently cover the target company’s and related third-parties’ assets and 
must exclude any findings that belong to other companies. In other words, the scoring system should 
be highly reliable (high true positive rate) and consistent (less false negative). 


There are no standards on scoring methodologies (yet) for risk scoring products. An easy-to- 
understand and consistent scoring is very important when assessing the cyber risk posture of your own 
company and your third-parties. 


Some companies use numeric scoring (0 to 900 scoring) and some use letter grades (A to F scoring). 


2.1.1 Risk Identification 


2.1.1.1 Asset Identification 

As the old security adage goes, “You can’t protect what you don’t know.” Therefore, the first task is to 
identify and create an inventory of all physical and logical assets that make up the system that is within 
the risk assessment scope. When identifying the assets, it is important to take note of those that are: 


e Crown jewels - These assets are critical to achieving the overall business objectives and are 
usually what the attackers would actively seek to exploit. Example: In a EPES infrastructure of 
a power station, a Programmable Logic Controller (PLC) controlling the main infrastructure is 
likely to be considered a crown jewel as it directly affects the consumption of electricity — the 
overall business objective of the power station. An attacker who wants to disrupt power 
generation is likely to want to compromise and manipulate the logic within the PLC. 

e Stepping stones - These assets are resources that attackers would want to take control and 
leverage to pivot across network segments before reaching the crown jewels. Example: In a 
typical Windows environment, an Active Directory (AD) server that maintains/validate user 
login credentials to multiple servers is likely to be considered a stepping stone, as it provides 
a bridge for attackers to pivot into these servers. 


The asset inventory list is used to consolidate and create a network architecture diagram that provides 
a visual representation of the interconnectivity and communication paths between the assets. It 
Identifies and labels all entry points (i.e. attack vectors) into the system, as well as the stepping stones 
and crown jewels. This would help facilitate the next task to identify threats. 
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2.1.1.2 Identify Threats 

With the asset inventory list and network architecture diagram, it is possible to identify the threat 
events that could exploit the vulnerabilities for each asset. There are many publicly available sources 
with threat libraries that can be referenced for identifying threat events. Threats events can be 
systematically identified by taking the steps below: 


l. Apply the threat events in the referenced libraries to each asset that presents an entry point 
(i.e. attack vector) to the system. 
Il. Document relevant threat events that are applicable to each asset. 
II. Enumerate through the assets and repeat steps (i) and (ii) above until all key assets (especially 
crown jewels and stepping stones) are included. 


When enumerating through the assets to identify possible threat events, always keep in mind the 
attack stages of the Cyber Kill Chain. The Cyber Kill Chain is a useful model that maps out steps and 
goals of a typical real-world attack. Threat events that are relevant to assets at the system perimeter 
are typically categorised in the early stages of the Cyber Kill Chain. As we move deeper into the system, 
threat events that are more relevant would be categorised in the later stages of the Cyber Kill Chain 
(e.g. lateral movement, command and control). 


2.1.1.3 Construct Risk Scenarios 

Constructing risk scenarios is the last task to complete the Risk Identification. This task aims to create 
“what could go wrong” scenarios that provide a realistic and relatable view of risks based on the 
business context, system environment and pertinent threats. A well-constructed risk scenario 
facilitates communication to stakeholders and allows for structured analysis of risks in subsequent 
steps. A risk scenario should articulate the following four (4) key elements: 


e Asset - An object of value that has been identified 

e Threat event - An attack event that has been identified 

e Vulnerability - A weakness in the asset or processes supporting the asset that can be exploited 
by the identified threat event. The vulnerability may have surfaced in recent audits and/or 
penetration-tests or may be relevant to the environment due to the use of certain 
technologies. 

e Consequence- The direct result of the threat event. 


2.1.2 Risk Analysis 

Risk analysis refers to the review of risks associated with the particular action or event. The risk analysis 
is applied to information technology, projects, security issues and any other event where risks may be 
analysed based on a quantitative and qualitative basis. Risks are part of every IT project and business 
organisations. The analysis of risk should be occurred on a regular basis and be updated to identify 
new potential threats. The strategic risk analysis helps to minimise the future risk probability and 
damage. The step 1 of the risk analysis process on the approach of S-RAF is to determine the likelihood. 
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2.1.2.1 Determine Likelihood 

As a general guidance, the likelihood of cybersecurity risks should be assessed from the perspective of 
threats and vulnerabilities. One method to determine the cybersecurity risk likelihood is to consider 
the following factors: 


e  Discoverability - How easy would an adversary be able to discover the vulnerability of an asset? 
This is dependent on the availability of information about the vulnerability and the exposure 
of the vulnerable asset. 

e Exploitability - How easy would an adversary exploit the vulnerability of an asset? This is 
dependent on the access rights, complexity of tools, as well as technical skills required to carry 
out the attack. 

e Reproducibility - How easy would an adversary be able to reproduce the attack on the asset? 
This is dependent on the complexity of the exploit customisation and the environmental 
conditions required to carry out the attack. 


2.1.2.2 Calculate Impact 

In general, the manifestation of a risk scenario can compromise the confidentiality, integrity and/or 
availability of assets (e.g. data, equipment, operations). Any compromise of the assets will translate to 
adverse impact. 


2.1.3 Risk Calculation 

Each top-level criterion is represented with a tree of subcriteria. Criteria not composed of other criteria 
are assigned a score either by experts or based on a set of metrics. For example, the score of the 
financial gain criterion of risk may be estimated either directly by experts or based on monetarily 
measurable metrics. 


Figure 2: Risk Calculation Impact Categories 
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2.1.3.1 Determine and Prioritise Risk 

Risk is a function of the likelihood of a given threat event exploiting a potential vulnerability of an asset 
and resulting impact. This can be diagrammatically presented using a risk matrix. The following Figure 
3 below is a sample 5-by-5 risk matrix for determining risk level for each risk scenario, where risk level 
is a correlation of "Likelihood" and "Impact", determined from the Risk Analysis conducted in the 
previous step. 


Low 


Very Low 1 


Rare Unlikely . 


Figure 3: Risk Matrix 


For each risk level derived, compare it against the risk tolerance level defined by the organisation. Risk 
scenarios with risk levels above the tolerance level must be prioritised for treatment until the risk levels 
fall to within the tolerance level. When prioritising risks for treatment, the expected duration should 
also be established. 


2.1.3.2 Risk Report 

A risk assessment is incomplete vvithout documentation. The outputs from previous steps must be 
clearly documented in a Risk Report for communication to stakeholders. A Risk Register is a record of 
all the risk scenarios identified, including their determined risk level. The Risk Register is a living 
document to be regularly reviewed and updated to ensure that the organisation’s management has 
an up-to-date picture of the organisation’s cybersecurity risks when making risk-informed decisions. It 
should minimally contain the following: 


e Risk scenario — A scenario articulating how a threat event could exploit a potential vulnerability 
of an asset to create an adverse impact. 

e identification date — The date when the risk scenario is identified. 

e Existing measures - The current measures in place to address the risk scenario. 

e Current risk — The determined risk level (combination of likelihood and impact) of risk scenario 
after taking into account existing measures. 

e Treatment plan — The planned activities (e.g. deploying additional measures) and timeline to 
treat the current risk to an acceptable level (i.e. within organisation's risk tolerance level). 

e Progress Status — The status of implementing the treatment plan. 
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e Residual risk — The determined risk level (combination of likelihood and impact) of risk scenario 
after treatment plan is implemented (i.e. current risk with additional measures applied). 

e Risk Owner — The individual or group responsible for ensuring that the residual risks remain 
within the organisation's tolerance level. 


2.2 EPES Best Practices, Security Issues and Assessment 

The starting point of the analysis has been a description of challenges in the energy sector that need 
to be addressed. In order to derive the challenges in the energy sector, high-level objectives have been 
agreed, which are expected to be common targets among all stakeholders in the energy sector. Today's 
energy infrastructure and market have been reflected against these high-level objectives and 
challenges have been derived accordingly. The challenges described are based on an operational 
viewpoint, i.e. they reflect challenges in daily operation but do not necessarily imply that support from 
a governmental authority is required to overcome these challenges, as some may be solved with other 
means. 


Critical infrastructures provide essential services that underpin the smooth functioning of a modern 
society and serve as the backbone for the economic activities. These critical infrastructures include the 
energy, telecommunication, finance, health, and transport sectors. The energy infrastructure is 
arguably among one of the most complex and critical infrastructures as these other sectors depend 
upon it to deliver their essential services. Therefore, unavailability in supply of energy has a high 
potential impact on economy and proper functioning of the civil society that can last longer than the 
time of the incident itself. A potential disruption for a long period of time could affect the society, 
industry and trade with a high risk of impact on the modern society. 


Digital technologies are playing an increasingly important role in the energy sector. A smarter energy 
system can perform power generation, transmission, network management and market related tasks 
with better precision and faster response times than a human-dependent system, thereby optimising 
energy management, prioritising usage, and setting policies for quick response to outages. Energy 
control systems include a hierarchy of interconnected physical and electronic sensing, monitoring, and 
control devices, mostly acting in real-time and typically connected to a central supervisory station or a 
control centre, but also extending up to customers with devices such as Smart Meters. Industrial 
control systems (ICS) encompass supervisory control and data acquisition (SCADA) systems used to 
monitoring and control operations that in case of energy transport and distribution networks are 
widely dispersed. Distributed control systems (DCS) are used for single facilities or small geographical 
areas. Control systems are connected to remote components such as remote terminal units (RTU) and 
programmable logic controllers (PLC) that monitor system data and initiate programmed control 
activities in response to input data and alerts. SCADA systems collect, display and store information 
from remotely located data collection transducers, sensors, control equipment's, devices and 
automated functions. The lack of real information and research on the EPES section portrays the huge 
gap between Cybersecurity and the aforementioned digital systems. 


2.3 SDN-microSENSE Risk Assessment Framework (S-RAF) 
For the scope of SDN-microSENSE we focused on creating an S-RAF solution which will differentiate 
from the already developed one and will complement the security of EPES infrastructure. In the rest 
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of this section we present a vvrap-up of the methodology developed and the key points of 
differentiation between the developed solution and the methods described above. 


2.3.1 SDN-microSENSE Risk Assessment methodology 


The collaborative Energy Chain Risk Assessment (ECRA) methodology of SDN-microSENSE has been 
defined and presented in D3.1 [2], but for comprehension purposes it is briefly presented here as well. 


Due to the distributed nature of the decentralised energy system, the ECRA methodology takes into 
account the collaborative aspects needed to involve all stakeholders (i.e. personnel at different places 
or task roles) of the energy components. 


Additionally, this distributed nature makes it important to calculate the cumulative risk assessment. 
Cumulative manner considers the risk imposed to a specified asset asa product of the propagated risk 
which derives by the exploitation of a vulnerability of an asset that belongs in the same group of assets 
with the former one. This risk assessment approach enables one to perceive the security state at the 
level of mission-critical assets that belong either in the same business workflow, or in the same 
physical (or virtual) networks. In contrast, Individual risk refers to the risk imposed by an identified 
threat to a specific asset. This risk measurement is asset-centric as it enables a security specialist to 
focus on an asset of special interest and analyse its attack surface. This approach is of major 
importance when it comes to the protection of mission-critical assets and services in the EPES. 


The methodology follows standardised notations and consists of seven steps (step O to step 6), which 
are presented below, along with a short description. 
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Definition 
of scope 


Analysis 
of the 
EPES 


Risk Threat 
Mitigation Analysis 


Risk Vulnerability 
Assessment Analysis 


Impact 
Analysis 


Figure 4: ECRA basic steps 
e Step 0: Scope of the Energy Chain Risk Assessment (ECRA) 


The initial step of the assessment, where the risk assessor selects the Energy Chain under 
consideration and defines the goal, the scope, and the outcome of the assessment. 


e Step 1: Analysis of the EPES 


The EPES under examination is decomposed, and its business processes and the cyber assets that 
comprise it (along with their interrelations) are defined and modelled using the SDN-microSENSE 
taxonomy (defined in D3.2 [3]). 


e Step 2: EPES cyber threat analysis 


Individual cyber Threats against the EPES cyber assets are identified based on Energy Chain 
participants expertise and knowledge, with usage of existing repositories of cyber threats. 


e Step 3: Vulnerability Analysis 


Vulnerabilities that exist in the cyber assets of the EPES are identified, based on data extracted 
from existing repositories of vulnerabilities and vulnerability scanners. Each individual vulnerability 
is first assessed and attack paths that would allow an attacker to reach one or more target assets 
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from one or more entry points/assets are discovered. An assessment is performed to calculate the 
cumulative vulnerability level of the attack paths. 


e Step 4: Impact Analysis 


The impact of the successful exploitation of each vulnerability is defined for individual assets and 
then the notion of cumulative impact is provided. 


e Step 5: Risk Assessment 


In this step, the methodology performs the risk assessment and computes the risk of individual 
assets and the commutative risk for asset chains. 


e Step 6: Risk mitigation: Selection of security controls 


Appropriate security actions are performed for mitigating attacks. To do so, security controls 
(extracted by guidelines, standards and concretely defined actions) will be selected and the risk 
will be recalculated. 


2.3.2 OLISTIC as part of SDN-microSENSE Risk Assessment 


OLISTIC is UBITECH’s Enterprise Risk Management Suite and, among other complementary 
functionalities, is designed to offer an enterprise-scale cybersecurity risk management framework. In 
short, OLISTIC enables risk management across all operational domains of a company/organization and 
promotes the adoption of a security-by-design modus operandi. 


OLISTIC acknowledges that an efficient and comprehensive cybersecurity risk management policy is 
the foundation of any proper business continuity plan. OLISITC builds upon the following principles: 


Risk Assessment Quality is Key: The vast majority of existing cybersecurity risk management solutions 
model risk as a static property of each asset. OLISTIC provides a graph-based asset inventory module, 
so that to facilitate the visualization of asset interdependencies that can be used by attackers to cause 
damage. 


Act Proactively, instead of Reactively: OLISTIC aims to provide the means to a security administrator 
of an organization to act proactively, instead of reactively. As there is no such thing as being 100% 
secure 100% of the time, being proactive pays off. OLISTIC innovates by offering an environment to 
serve as a security playground. Security and compliance officers can assess cyber risks and consider 
the existence and manage defensive strategies to retain confidentiality, integrity and availability risks 
at a minimal level. 


Interoperability & Completeness: OLISTIC is built to be interoperable. Given the cybercrime epidemic, 
it embraces a best-of-breed approach to promote security-by-design. Its purpose is not to replace 
existing niche cybersecurity solutions (e.g. intrusion detection & prevention, anomaly detection, etc.). 
On the contrary, it acts complementary and offers an insightful risk analysis across all business 
processes of an organization. 


The Risk Assessment Methodology is based on the following workflow: 


1. Build the Asset Inventory 


© SDN microSENSE consortium Page | 22 
Public document 


(x) SDN-uSense 
D3.5 


Version 1.0 


Define all Business Services (optional) 

Assess the Cyber Risk 

Evaluate the existence of different Defensive Strategies 

Select and apply the optimal defensive strategy and repeat steps 4-5 (or 1-5) (unfortunately 
security is an iterative process). 


Ur. po IN 


Asset inventory: OLISTIC enables the analyst to treat every part of an organization as an asset (both 
tangible and intangible, such as servers, workstations, people etc.), as it capitalizes in a rather abstract 
model that offers great flexibility. In fact, OLISTIC allows the declaration of any, customer or domain- 
driven, arbitrary number of asset properties (e.g. multiple IP addresses, MAC addresses, tag numbers, 
product identifiers, manufacturer settings etc.) to offer a perfect fit to the peculiarities of the 
underlined infrastructure. Based on this approach, it employs a graph to model the asset inventory 
and describe all possible interdependencies among assets. Thus, OLISTIC deliver an asset-centric risk 
assessment approach. In addition, it syncs vulnerabilities, threats and controls from numerous well- 
known security standards and libraries (e.g. NIST CVE, ISO 27001 & 27005, OWASP, etc.), while it 
provides a generic and extensible system model capable of supporting any custom set of 
vulnerabilities, threats and controls. Based on the above, OLISTIC could be seen as an embedded asset 
management system. Asset Inventory is supported through OLISTIC's native asset editor, by using 
predefined CSV templates, or through the integration of vulnerability scanners, such as OpenVAS, in 
order to import assets, attributes and relationships. 


Business Services: These are logical groups of assets that define the granularity in monitoring the cyber 
risk. This feature enables the analyst to mask organizational units, departments, and ERP business 
processes as business services and manage risks from an operational standpoint. OLISTIC supports 
unlimited business services, while an asset can be associated with multiple business services. OLISTIC 
ships with a default business service that refers to the asset inventory as a whole. 


Risk Assessment: It calculates the cyber security risks for all assets or for an individual business service. 
OLISTIC offers analytical reporting dashboard functionalities that aim to assist a) IT people in 
addressing security issues and b) executives in having a broad overview of the risk within the 
organization. Each risk assessment execution is effectively a gap analysis between the current state 
and the desired security goal, while it also assists to monitor the security state of the monitored 
infrastructure in time. OLISTIC's risk engine is highly optimized and scales almost linearly to the asset 
inventory size. Through reporting dashboards, the analyst is in position to review the vulnerabilities 
and threats pending treatment and analyse vulnerabilities in accordance with their impact on 
confidentiality, integrity, and availability of each asset. 


Defensive Strategies: OLISTIC offers a module for managing the consideration of defensive strategic 
for mitigating risks. In this way, the security analyst is able to confirm the status of security and privacy 
within the organization and estimate the distance towards the ultimate security goal. OLISTIC gives the 
ability to consider and evaluate an infinite number of defensive strategies based on controls from 
numerous well-known security standards and libraries. After evaluating the applicability of defensive 
actions, the security analyst repeats steps 4-5 (or 1-5) of the methodology described in order to 
maintain a timely overview of the cyber security risk level of the organisation. 
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The abovementioned operations form the basic functional structure of OLISTIC. The interoperable and 
flexible modelling of OLISTIC enables the adoption to several business environments, but its 
integration requires the development of additional features to fit to the peculiarities of each case. 
Thus, in the context of SDN-microSENSE, major updates have been triggered in order to address the 
need for a collaborative risk assessment framevvork for EPES. 


1. Usage of updated model that supports EPES 


The distributed nature of the EPES posed the requirement for the development of a methodology 
which considers the collaborative aspects and the involvement of multiple stakeholders (i.e., personnel 
at different places or task roles) in the risk assessment process. In this direction, and as will be 
highlighted also in the following listed items, several changes were triggered to OLISTIC's engine to 
support the adoption of the EPES ecosystem. The support of assets, considering of a wide range of 
legacy ICT and industrial devices, including older legacy SCADA and ICS devices, loT components, and 
SDN assets required the extension of the inherent model. OLISTIC has been updated to become 
compatible with industrial and Power-specific standards for enabling risk assessment and the 
utilization of controls for the energy chain. Last but not least, several updates have been triggered to 
enable interoperable interaction with other tools. The aforementioned are a fraction of the changes 
made to OLISTIC's model for fitting to the EPES and energy chain. More specific points are listed below. 


2. Collaborative Risk Assessment with the cumulative RA 


In order to address the need for a collaborative risk assessment framework, we took advantage of the 
graph-based modelling of assets interdependencies used in OLISTIC to deliver a collaborative scheme 
of measuring the risk in a cumulative manner. More specifically, through the interdependency graphs, 
the risk assessment methodology has been extended to, not solely focus on measuring the risk for 
individual assets, but to uncover the risks which can be raised as a result of propagated threats or the 
ability of an attacker to penetrate further into the network. The collaborative aspect of the risk 
calculation is the utilisation of globally accepted standards such as CVSS. This option enabled the risk 
quantification to be compatible to the wide variety of legacy ICT and energy and SDN-specific assets. 


3. Connecting with AIDB for EPES asset retrieval 


As mentioned before, asset inventory is supported through OLISTIC's native asset editor or by using 
predefined CSV templates to import assets, asset attributes and relationships. Although those 
functionalities are important for managing the assets participating in the risk assessment process, 
these methods do not scale when the assessment methodology targets dynamic and distributed 
infrastructures like EPES. To this end, the asset inventory process has been extended to retrieve asset 
information from the Asset Inventory Database of the SDN-microSENSE architecture. By integrating 
this functionality to the already established asset management processes, S-RAF guarantees the 
always up-to-date overview of the infrastructure and, consequently, the accurate risk assessment. 


4. Connection with eVul for automated analysis of vulnerabilities in the EPES environment 


The dynamic asset inventory implies the existence of a dynamic process to offer enhanced 
observability to assets for identifying possible vulnerabilities. To do so, OLISTIC has been extended by 
integrating eVul tool for dynamically scanning the network assets and detect vulnerabilities. This 
feature supports and completes the inherent model that considers vulnerabilities from numerous well- 
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known security standards and libraries (e.g. NIST CVE, OVVASP, etc.), while potentially being used 
interchangeably with the integrated OpenVAS vulnerability scanner. 


5. Extending OLISTIC model and components for retrieving alerts from XL-SIEM 


The model of OLISTIC has been extended in order to handle the input from threat detection tools. 
More specifically, S-RAF is able to dynamically consume alerts coming from the XL-SIEM deployed in 
the SDN-architecture. In this vvay, the dynamic asset inventory and vulnerability discovery is supported 
by the detection of threats against the assets. This feature offers a more detailed overvievv of the cyber 
risks and the security status of the EPES infrastructure. 


6. Providing Incidents based on the Risk Assessment as output to SDN-SELF and ARIEC 
components of SDN-microSENSE 


Given the extensions for dynamically managing multiple inputs sources, OLISTC has been extended to 
deliver the Risk Assessment output to the SDN-SELF components, so that to base self-healing actions 
on evidences (i.e., incidents) and proceed to informed decisions. The consideration of information 
regarding the assets, the vulnerabilities and threats in the risk calculations and the calculation of 
cumulative risk due to attack propagation, can offer added value to components that exploit the 
output of S-RAF. 


7. Integrating Apache Kafka as message queue that can be used by both internal and external 
components 


In order enable interoperability with other tool, S-RAF adopts the utilisation of Apache KAFKA to act 
as an integration point and offer data persistency. In this way, a dynamic data pipeline is formed for 
sharing the outcome of S-RAF functions through a message queuing architecture. 


8. Compatibility with MISP format 


MISP is the prominent open standard for threat information sharing. In the context of SDN- 
microSENSE, upon the detection of offensive actions, the XL-SIEM will forward alarms to the CIS 
component. The CIS transforms the output of XL-SIEM into MISP format. OLISTIC has been extended 
for being compatible with MISP format so that to ensure interoperability with other architectural 
components. 


2.3.3 SDN-microSENSE Risk Assessment Framework (S-RAF) Differentiations 
In this section we highlight three key points of differentiation between the adoption of ECRA/S-RAF in 
comparison to other risk assessment solutions. 


2.3.8.1 | Cumulative Risk Assessment 

Current tools assess the risks from threat events as a combination of likelihood and impact. The level 
of risk associated with identified threat events represents a determination of the degree to which 
organisations are threatened by such events. Organisations make explicit the uncertainty in the risk 
determinations, including for example, organisational assumptions and subjective 
judgments/decisions. Organisations can order the list of threat events of concern by the level of risk 
determined during the risk assessment—with the greatest attention going to high-risk events. 
Organisations can further prioritise risks at the same level or with similar scores. Each risk corresponds 
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to a specific threat event with a level of impact if that event occurs. In general, the risk level is typically 
not higher than the impact level, and likelihood can serve to reduce risk below that impact level. 
However, when addressing organisation-wide risk management issues with a large number of 
missions/business functions, mission/business processes and supporting information systems, impact 
as an upper bound on risk may not hold. For example, when multiple risks materialise, even if each risk 
is at the moderate level, the set of those moderate-level risks could aggregate to a higher level of risk 
for organisations. To address situations where harm occurs multiple times, organisations can define a 
threat event as multiple occurrences of harm and an impact level associated with the cumulative 
degree of harm. In order to tackle this lack of concrete methodology due to the difficulty of automating 
such process, we decided to add the cumulative part of risk assessment and calculation of risk. The 
calculation methodology has already been presented on deliverable D3.2 [3] and the formula used for 
the cumulative risk calculation as described also in section 4.5. 


2.3.3.2 Risk Assessment with Focus on EPES 

Finally, a critical infrastructure such as EPES contains many assets which may be cyber and physical. In 
order to infer the risk per asset, information regarding its vulnerabilities and impact level upon 
exploitation must be combined. The identification of such control elements constitutes the optimal 
defence strategy (Mitigation Strategy) tailored to the calculated cyber-risks. In the context of SDN- 
microSENSE, these controls basically reflect the controls identified form analysis of the standards in 
D3.1 [2]. Last but not least, the Risk levels of an asset is associated with the two variants of risk, namely 
the Individual Risk Level and the Cumulative Risk Level. 


2.3.3.3 Deep Insights on the security issues of EPES 

Through the inclusion of an engine that detects and manages vulnerabilities (eVul) and through 
integration with the other components of SDN-microSENSE (AIDB, XL-SIEM, output from EPES related 
honeypots), S-RAF is capable to provide also deep insights on the security issues, thus allowing 
administrators to monitor easily the security status of the examined EPES infrastructure. 
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3 SDN-microSENSE Risk Assessment Framevvork Architecture 
In this section we provide information about the design of the S-RAF and how it vvorks as part of the 
overall SDN-microSENSE framevvork. 


3.1 Architecture Overvievv - Conceptual Architecture 
This section presents how the components developed in this task fit in the general architecture of SDN- 
microSENSE, as presented in deliverable D2.3 [4]. 


Figure 5: SDN-microSENSE Architecture Structural View 


S-RAF is placed in the application plane and has been developed mainly in task 3.5, and is interacting 
with two other main components of SDN-microSENSE framework; the XL-EPDS responsible for 
identifying issues in the infrastructure, and the SDN-SELF that is responsible for the adaptations in the 
SDN fabric of the deployments. 


Taking a closer look on the initial conceptual architecture, as presented in Figure 6, S-RAF includes the 
Risk Level Assessment and the Vulnerabilities Management components and also includes the 
Honeypot Manager component that has been developed in task 3.3. Honeypots and the Honeypot 
Manager are described in detail in D3.3 [10], and therefore will not be examined in this deliverable. 


Honeypots Vulnerabilities 
Management Management 
Risk Level Assessment 


Figure 6: S-RAF in the Application Plane 
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Based on the vvork performed in VVP3 and as the focus of this deliverable is S-RAF itself, vve provide in 
Figure 7 belovv the internal conceptual architecture of S-RAF, along vvith the components of SDN- 
microSENSE that it has direct integration. 
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Risk Level Assessment 
Component 


Impact Analysis 
Component 
eVul OpenVAS 


Honeypot Manager 


Figure 7: General view of the components and the relationships with other components 


The internal components of S-RAF are presented in section 3.2. The S-RAF also interacts with other 
tools in the SDN-microSENSE ecosystem that are presented briefly below to assist the reader on 
understanding the design aspects of S-RAF. 


e S-RAF communicates with the Asset Inventory Database (AIDB): AIDB is a cross component 
which, not only supplies information to the Application/Management Plane and the Control / 
Management Plane layers, but also interacts with EPES in order to obtain information about 
Grid assets, and additionally SDN network assets. The planned AIDB usage by S-RAF is focussed 
on the query of network assets in order to get information about all hosts connected to the 
SDN network, regardless whether they present vulnerabilities or not. 

e S-RAF communicates with XL-EPDS through XL-SIEM to gather alerts and their corresponding 
metadata. These alerts are se nt through RabbitMQ. 

e S-RAF provides to the SDN-SELF (through the Electrical Data Analysis Engine (EDAE) 
component) information regarding the vulnerable assets and gathered alerts from the XL- 
EPDS, enhanced with risk information. 

e  S-RAF provides to the Anonymous Repository of Incidents (ARIEC) information regarding the 
cybersecurity events, enhanced with risk information 
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3.2 Structural and Components View - Presenting S-RAF Components 
In this section we describe the components of S-RAF and also the interfaces laying among them or with 
other external components. 


3.2.1 Functional View: Presenting S-RAF Components 
In this section we provide a description of the components of S-RAF with more details. 


3.2.1.1 Asset Identification Component 
This component is intended to store the assets (e.g. devices) that are connected to the EPES network 
and gathers as much information as possible from these devices. 


S-RAF will employ a graph to model the asset inventory and describe all possible interdependencies 
among the discovered assets. In this way, a comprehensive mapping is generated for the multiple 
assets of the EPES network. S-RAF offers a generic and extensible system model capable of supporting 
any custom set of vulnerabilities, threats and controls, which are related to the identified assets. In 
other words, it allows the declaration of any, customer and use case driven, arbitrary number of asset 
properties (e.g. multiple IP addresses, MAC addresses, tag numbers, product identifiers, manufacturer 
settings etc.). As assets are described as a topology, it is important to be able to store the assets based 
on the idea of interdependency graphs, and thus being able to store relationships between the assets. 
For this reason, Neo4j [11] is used. Neo4j has a flexible structure defined by stored relationships 
between data records, as each data record, or node, stores direct pointers to all the nodes it is 
connected to. 


The asset inventory can be created in different ways, mainly statically at this stage, but it is currently 
being integrated with the AIDB component for retrieving assets automatically. 


3.2.1.2 Threat Identification Component 

The threat identification component aims to identify the threats which are applicable to the EPES 
ecosystem. EPES is typically a mosaic of several technologies and hence, there is a wide range of threats 
that may target the components which may be distributed among the critical infrastructure and the 
power supply chain. The threat identification component uses a comprehensive dictionary of known 
patterns of attack employed by adversaries to exploit known weaknesses in cyber-enabled capabilities 
of EPES, and will enable the mapping between attack patterns and proper controls, which can be 
applied so as to minimise the risk level of EPES. 


The threat identification component receives input from the XL-EPDS tools of the SDN-microSENSE 
architecture regarding security events and attacks that threaten the infrastructural assets. 


3.2.1.3 S-RAF Dashboard and Controller 

S-RAF Dashboard has been implemented using Thymeleaf [12] and the S-RAF Controller is responsible 
to provide all REST calls needed by the Dashboard of S-RAF. This is a core component of OLISTIC that 
has been extended for the purpose of S-RAF adaptations. 


3.2.1.4 Impact Analysis Component 

The impact analysis component defines a mapping from the three-security criteria (Confidentiality, 
Integrity and Availability) covered in the CVSS Impact metric onto the five-tier scale ranging from “Very 
Low” to “Very High”. This provides a single estimation for the overall impact of a specific 


© SDN microSENSE consortium Page | 29 
Public document 


(x) SDN-uSense 
D3.5 


Version 1.0 


asset/vulnerability combination. Given that EPES is by-design a distributed ecosystem of diverse 
software and hardware components, the impact analysis component will be based on asset chainsin 
order to estimate the cumulative impact that derives from the interconnections of the assets. 


3.2.1.5  Honeypots Management Component 

The Honeypot Manager and the whole integration of honeypots in SDN-microSENSE has been 
described in detail in deliverable D3.3 [10]. In short, the Honeypot Manager has two main 
functionalities in the SDN-microSENSE: 


1. Provides means to develop in an automatic way those honeypots that the security operator or 
manager decide to deploy in the network. 

2. Processes the information about unknown anomalies (like zero-day attacks) provided by the 
XL-SIEM and indicates to the SDN controller the required information to re-arrange the 
honeypots network in order to collect information for these unknown anomalies detected by 
the ML models of the XL-EPDS. 


This component consists mainly in two modules: 


e The front-end is composed by subcomponents in charge of presenting to the Security operator 
all the information that could be useful for managing the honeypots deployed in the EPES 
network. This module is a web application developed in HTML5 + CSS3 technologies. The 
selected scripting language to perform all the operations is AngularJS 

e The back-end component oversees the execution of the two functionalities explained above. 
The Honeypot Manager's back-end consists of a Spring Boot application, managed by Maven, 
and contains the following modules: 

o Database: A MySQL database is accessed using Spring JPA Repository technology. 

o REST API: A definition of REST services using Spring REST technology. 

o Security: All REST services are secured through a role-based system. In addition, to 
access each of the REST services it is necessary to be authenticated through JSON Web 
Tokens (JWT technology). 


Therefore, design wise, since D2.3 [4] we consider Honeypot Manager as part of the overall S-RAF 
solution; however the communication with the other parts of S-RAF is performed through the 
integration with the XL-SIEM. 


3.2.1.6 | Vulnerability Management Component 

The vulnerability Management Component is utilized to analyse the vulnerabilities of assets in the 
SDN-microSENSE infrastructure. This component capitalises on the use of eVul tool, offered by Ayesa, 
for detecting and managing vulnerabilities on hosts connected to the SDN network. The integration of 
the eVul Vulnerability manager aims to discover what network assets present vulnerabilities and may 
trigger the raise of risk level. 


The risk level is based on the standard CVSS and depends on the vulnerability type, i.e., the exact CVE 
id. The Risk level is a number between 0 and 10, and can be classified following severity ranges, as 
shown in Table 1. 
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Table 1: Vulnerability risk level ranges 


Nonetheless, the vulnerability manager might intentionally change the risk level taking into account 
concrete hosts. The following diagram depicts the information returned by the Vulnerability Manager 
to the Impact Analysis component of the S-RAF risk assessment engine. 


HOST VULNERABILITY 
-IP <| -cve iD 
- MAC - RiskLevel 

- Status 


Figure 8: Vulnerability info 


The vulnerability manager component creates a new instance workflow to follow up every detected 
vulnerability. Below, the vulnerability life cycle is depicted by a state diagram. The Vulnerability API 
will return active vulnerabilities. 


Rejected 


Figure 9: Vulnerability manager — Vulnerability life cycle 


This component counts on two main modules: 
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e Front-end. It is a Web application based on HTML5, Java, Angular 7 technologies. This 
application allows a user to manage detected vulnerabilities through a workflow with different 
stakeholders complying a preconfigured BPM, configure notification and make follow up. 

e Back-end. The back-end is based on a microservices architecture and it is integrated seamlessly 
with the GridPilot platform. Microservices devoted to eVul employs: 

o Database: the RDMS PostgreSQL 
o External communications: API REST, API manager WSO2. 
o Internal communication: 

" synchronous by REST services 

= asynchronous by AMOP, RabbitMQ 


On top of the competitive advantages gained by the eVul integration, S-RAF inherits the existence of 
OpenVAS vulnerability scanner, which comes as an integrated tool in OLISTIC. Both tools can 
complement each other and offer enhanced visibility to the SDN-microSENSE infrastructure. 


3.2.1.7 Risk Level Assessment Component 

This component aggregates the inputs of the above-mentioned components of the S-RAF in order to 
perform the final risk assessment. The mapping generated among all the assets in the EPES, the 
identified vulnerabilities, the attacks and the possible applied controls will be used to estimate the 
overall security risk. 


3.2.1.8  Pub-Sub Queue (Kafka) 

An extension performed on OLISTIC for facilitating easier integration with other components of the 
SDN-microSENSE. More specifically, in the Publish-Subscribe system, messages are persisted in a topic. 
Unlike point-to-point systems, consumers can subscribe to one or more topics and consume all the 
messages in that topic. In the Publish-Subscribe system, message producers are called publishers and 
message consumers are called subscribers. Apache Kafka can handle a high volume of data and enable 
one to pass messages from one endpoint to another. Kafka is suitable for both offline and online 
message consumption. Kafka messages are persisted on the disk and replicated within the cluster to 
prevent data loss. Hence, Kafka is used as an intermediate entity which guarantees the continuous and 
fault-tolerant message and data exchanging among the sub-components of the SDN-microSENSE 
architecture that need to consume information from the risk assessment process. 


Kafka integration offers the following qualities to the S-RAF framework: 


e Reliability — Kafka is distributed, partitioned, replicated and fault tolerant. 

e = Scalability - Kafka messaging system scales easily without down time. The pool of Producers 
and Subscribers can be extended effortlessly and can cover future integration needs of the 
project. 

e Durability - Kafka uses distributed commit log which means messages persist on disk as fast 
as possible, hence it is durable. 

e Performance - Kafka has high throughput for both publishing and subscribing messages. It will 
maintain a stable performance even if more components are going to be integrated in the final 
framework. 


A stream of messages belonging to a particular category is called a topic. Producers are the publishers 
of messages to one or more Kafka topics. Producers send data to Kafka brokers, which are responsible 
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for maintaining the published data. Instead of storing all the messages of a partition in a single file, 
Kafka splits them into chunks called segments. Every time a producer publishes a message to a broker, 
the broker simply appends the message to the last segment file. Consumers read data from brokers. 
Consumers subscribe to one or more topics and consume published messages by pulling data from the 
brokers. The exact Kafka topics which will act as the actual integration endpoints with the rest tools 
will be documented in the context of the integration actions of WP7. 


3.3 Integration View — Presenting S-RAF Interfaces 
Based on the design and implementation aspects of S-RAF, the following interfaces were identified and 
implemented. 


e eVulto Impact Analysis Component Interface 

e AIDB to S-RAF Interface 

e  S-RAF to SDN-SEL Interface 

e S-RAFto ARIEC Interface 

e XL-SIEM to RAF Interface 

e Controller to Dash Interface 

e Risk Level Assessment Interface to Controller 

e Impact Analysis to Risk Level Assessment Interface 
e Assets Identification to Impact Analysis 


These interfaces are presented below in detail, as agreed and implemented by the corresponding 
partners in order to facilitate the actual integrated version of S-RAF. It has to be mentioned that as the 
integration of S-RAF with other SDN-microSENSE components will take place in the forthcoming 
months in the scope of WP7, the interfaces and dependencies mentioned here between S-RAF and 
external SDN-microSENSE components (AIDB to S-RAF Interface, S-RAF to SDN-SEL Interface, S-RAF to 
ARIEC Interface, XL-SIEM to RAF Interface) might be updated or changed. The examples that 
accompany the interfaces definitions are based on fictional data and not on real assets and scenarios, 
due to privacy reasons. 


3.3.1.1  eVul to Impact Analysis Component Interface 

Description This interface aims to define the interaction between eVul and the core risk 
assessment engine of S-RAF. Note that, this interface refers to the internal 
integration of eVul to the vulnerability management component of S-RAF. 

Component providing | eVul 

the interface 

Consumer components Impact Analysis Component 

or External Entities 


Type of Interface REST 

Input data / Output Data Methods or endpoints of Parameters of the Return Object or Values 
the interface method of the method 
Get active vulnerabilities assetiD Json object with 
per asset vulnerabilities (see 


example below) 
Constraints / Comments — AssetlD should be known 
Responsibilities AYESA 
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Table 2: Details of the eVul-RA Interface 


An example of the response of the RAF-eVUL interface is provided belovv. 


"invExternalId":"0.0.0.1 ", 
"sdnIP":"0.0.0.1", 
"sdnMAC":"00:00:00:00:00:01 ", 
"vulnerability": [ 
{ 
"cve id": "CVE-2013-7512" 
"cvss, score": 5.45 
"sdnPort": null 


"cve. id": "CVE-2014-1334" 
"cvss, score": 9.45 
"sdnPort": null 


"invExternalId":"0.0.0.2", 
"sdnIP":"0.0.0.2", 
"sdnMAC":"00:00:00:00:00:02", 
"vulnerability": [ 
{ 
"cve_id": "CVE-2013-7512" 
"cvss_score": 5.45 
"sdnPort": null 


"cve id": "CVE-2014-1334" 
"cvss, score": 9.45 
"sdnPort": null 


3.3.1.2 AIDB to S-RAF Interface 

Description This interface aims to define the interaction between the Asset Inventory | 
Database (AIDB) and the core risk assessment engine of S-RAF. Note that, this | 
interface refers to the integration of AIDB with the Asset Identification | 

| Component of S-RAF. 

Component providing AIDB 

the interface 

Consumer components Asset Identification Component, eVul 

or External Entities 


Type of Interface  — | REST | | 

Input data / Output Data Methods or endpoints of Parameters of the Return Object or Values 
the interface method | of the method 
/topology_query N/A [ 

{ 
"invExternalld": 
"string", 
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"installations": "Yes", 
"elements": "Yes", 
"downstream": "Yes", 
"topology": "Yes" 
} 
] 
N/A { 
/assets_inventory_query "invExternalld": 
"string", 
"differentNet": "Yes", 
"border": "Yes", 
"invAssetType": "Yes" 
} 
* AIDB offers an extended API that exposed with Swagger!, and in the scope of 
WP7 integration further REST calls might be used. 
Constraints / Comments  - 
Responsibilities AYESA 
Table 3: Details of the AIDB-RAF Interface 


An example of the response of the AIDB-RAF interface is provided below. 


"invExternalld";"EX SDN CONTROLLER, UCO”, 
"invExternalName":" EX SDN CONTROLLER, UCO”, 
"invClass":" ELEMENT", 
"invNetLevel":"SDN_CONTROLLER_LEVEL", 
"invAssetType":"SDN Controller", 
"invState":"CONN_E", 

"invFather":"0.0.0.1", 

"invAttribute Values": [ 

{ 

"attribute":"sdnDriver", 
"value":"Northbound" 

}, 

{ 
"attribute":"sdnEndpoint", 
"value":"sdnEndpoint1" 

} 

] 
^ 
{ 

"invExternalld":"0000000000000001", 

"invExternalName":"0000000000000001", 

"invClass":"ELEMENT", 

"invNetLevel":"SDN_SWITCH_LEVEL", 

"invAssetType":"SDN_SWITCH", 

"invState":"CONN_E", 

"invFather":null, 

"invAttributeValues":[ 

{ 
"attribute":"InvDescription", 
"value" :null 


b 


relationships":null 


1 https://swagger.io/ 
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{ 
"attribute":"sdnManufacturer", 
"value":"Nicira, Inc." 

}, 

"attribute":"sdnSwDesc", 
"value":"2.3.90" 


"relationships": [ 


"relationshipId":"1", 
"externalIdA":"0000000000000001 ", 
"externalldB":"0000000000000002", 
"enable":true, 
"weight":1.0 

}, 

{ 
"relationshipId":"2", 
"externalIdA":"0000000000000002", 
"externalIdB ":"0000000000000001 ", 
"enable":true, 
"weight":1.0 

}, 

{ 


"relationshipId":"3", 
"externalldA":"000000000000000 1", 
"externalldB":"0000000000000003", 
"enable":true, 
"weight":1.0 

}, 


"relationshipId":"24", 
"externalIdA ":"0000000000000003", 
"externalIdB ":"0000000000000001 ", 
"enable":true, 
"weight":1.0 

}, 


"relationshipId":"4", 
"externalIdA":"0000000000000001 ", 
"externalldB":"0000000000000004", 
"enable":true, 
"weight":1.0 

}, 

{ 


"relationshipId":"5", 
"externalIdA":"0000000000000004", 
"externalldB":"0000000000000001", 
"enable" :true, 

"weight":1.0 


3.3.1.3  S-RAF to SDN-SELF Interface 
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Name: RAF-EDAE 
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Description This interface aims to define the interaction between the core risk assessment 
engine of S-RAF and EDAE tool from the SDN-SELF. This interface aims to make 
available the risk assessment output to the self-healing component through a 
Kafka data pipeline. 

Component providing  S-RAF (Kafka) 

the interface 

Consumer components SDN-SELF (ADAE) 

or External Entities 


Type of Interface Kafka 

Input data / Output Data Methods or endpoints of Parameters of the Return Object or Values 
the interface method of the method 
sraf.out.adae None. It is a pub sub | Json object with output 


interface. of alarms and risk 
assessment results (see 
example below) 
Constraints / Comments  - 


Responsibilities UBITECH 
Table 4: Details of the RAF-EDAE Interface 


An example of the response of the RAF-EDAE interface is provided below. 


{ 
"timestamp":"2020-07-15T12:34:28.743+0000", 
"xl siem rule":( 

"crit level":3, 
"description":"Nmap Scanning.", 
"sourceIP":"0.0.80.7", 
"firedtimes":5, 
"groups":[ 
"pam", 
"syslog" 
l 
"assets":[ 
"asset 00001", 
"asset 00002" 
] 
} 


isk_assessment":{ 
"ass1":{ 
"ip":"0.0.0.1", 
"id":"asset_00001", 
"previous_risk":"L", 
"current_risk":"M", 
"vulnerabilities": [ 
"CVE-2019-1347", 
"CVE-2019-1326" 
iF 
"dns name":"assetl name" 
) 
"ass2":{ 
"ip":"0.0.0.2", 
"id":"asset_00002", 
"previous_risk":"VL", 
"current_risk":"M", 
"vulnerabilities": [ 
"CVE-2019-1293" 
] 


, 
"dns name":"assetl name" 


) 


) 


istorical risk data":( 
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"previous risk level”: 'M'”, 
"current. risk level”: 'H” 


) 


"location" :"/Path/To/JSON" 
} 


3.3.1.4 S-RAF to ARIEC Interface 


| Name: RAF- ARIEC 
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_ the interface 


Description This interface aims to define the interaction between the core risk assessment 
engine of S-RAF and ARIEC. This interface aims to make available the risk 
assessment output that complements the identified security events of XL-EPDS 
components to ARIEC. 

| Component providing  S-RAF (Kafka) 


or External Entities 


Consumer components | ARIEC 


Type of Interface 


| Kafka 


Input data / Output Data 


Methods or endpoints of | 


_ the interface 


sraf.out.irec 


Parameters of 
method 
None. It is a pub sub 


interface. 


the | 
_ofthe method 


Return Object or Values | 


e Assets (from AIDB) 


e Vulnerabilities on 
assets (eVul) 
e Detected events 


against assets (from 
XL-SIEM through CIS. 


Note that this 
includes all the 
information as 


acquired from XL- 
SIEM (e.g. source IP 


of attack)) 
e Individual Risk per 
Asset - including 


previous state 


e Cumulative risk 
(including attack 
paths) 


| Constraints / Comments As ARIEC implementation described in D5.5 is considered Classified Information 


only a high-level description of the agreed interface is provided in this document. | 


| Responsibilities 


. UBITECH 


Table 5: Details of the RAF-ARIEC Interface 


3.3.1.5  XL-SIEM to RAF Interface 


Name: CIS-RAF 


Description 


| Component 
| the interface 


providing 


Atos CIS uses this interface, supported by a RabbitMQ server, to export alarms 
triggered by the XL-SIEM after being transformed to MISP format. 


Atos CIS 
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Consumer components Threat Identification Component 
or External Entities 
Type of Interface RabbidMQ 
Input data / Output Data Methods or endpoints of Parameters of the Return Object or Values 
the interface method of the method 
Exchange queue to read None. It is a push 
MISP alarms: interface 
atos.exchange.alarms.sd 
nmsense.cis 
Constraints / Comments  - 
Responsibilities ATOS 


Table 6: Details of the CIS-RAF Interface 
An example of the response of the CIS-RAF interface is provided below. 


{ 
"Event": { 
"id":"176565", 
"orgc id":"1", 
"org id":"1", 
"date":" 2020-08-05 ", 
"threat level id":"1", 
"info":"Denial of Service alarm", 
"published":false, 
"uuid":" 5fA46xxx6-xxxx-xxx-xxx-6e060axxxx", 
"attribute count": "7", 
"analysis":"2", 
"timestamp":"1598427862", 
"distribution":"O", 
"proposal email lock":false, 
"locked": false, 
"publish_timestamp":"0", 
"sharing group. id":"O", 
"disable. correlation":false, 
"extends uuid":"", 
"event creator email":"ruben.trapero @atos.net", 
"Org":{ 
"id":"1", 
"name":"Atos ARI CS Lab", 
"uuid":"5a579708-xxxx-x-xx-12xxxxc8" 


) 
"Orgc":( 
"id":"1", 
"name":"Atos ARI CS Lab", 
"uuid":"5a579708-xxx-x-xx-12xxxxc8" 
b 
"Attribute":[ 
{ 
"id":"5070300", 
"type":"ip-src|port", 
"category":"Network activity", 
"to ids":false, 
"uuid":"5f4612d6-xxx-xxx-xxxx-6e06xxx020f", 
"event id":"1765565", 
"distribution":"5", 
"timestamp":" 1598427862", 
"comment":"Source IP and port associated to the detected alarm.", 
"sharing group id":"O", 
"deleted" false, 
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"disable correlation":true, 
"object id":"O", 

"object. relation":null, 
"value":"0.0.0.0|1 11", 
"Galaxy":[ 


l, 
"Shadow Attribute":[ 


}, 
{ 


"id":"5070301", 

"type":"ip-dst|port", 

"category":"Network activity", 

"to ids":false, 
"uuid":"5f4612d6-xxxxx-xxxx-xxxxx-6e06xxx020f ", 
"event id":"1765565", 

"distribution":"5", 

"timestamp":" 1598427862", 

"comment":"Destination IP and port associated to the detected alarm.", 
"sharing group id":"O", 

"deleted" false, 

"disable correlation":true, 

"object id":"O", 

"object. relation":null, 

“value”: '0.0.0.0)397”, 

"Galaxy":[ 


l, 
"Shadow Attribute":[ 


"1d" :" 5070302", 

"type":"other", 

"category ":"External analysis”, 

"to ids":false, 
"uuid":"5f4612d7-xxx-xxx-xxx-6e06xxx020f ", 
"event id":"1765565", 

"distribution":"5", 

"timestamp":" 1598427863", 

"comment":"Risk value evaluated by XL-SIEM", 
"sharing group id":"O", 

"deleted" false, 

"disable correlation":true, 

"object id":"O", 

"object. relation":null, 

"value":"8", 

"Galaxy":[ 


l, 
"Shadow Attribute":[ 


}, 
{ 


"id":"507033", 


"type":"other", 
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"category":"External analysis”, 

"to_ids":false, 
"uuid":"5f4612d7-xx-xxx-xxxx-6exxxx020f', 
"event id":"1765565", 

"distribution":"5", 

"timestamp":" 1598427863", 
"comment":"Priority value evaluated by XL-SIEM”, 
"sharing group id":"O", 

"deleted" false, 

"disable correlation":true, 

"object id":"O", 

"object. relation":null, 

"value":"5", 

"Galaxy":[ 


l, 
"Shadow Attribute":[ 


"id":"500304", 

"type":"other", 

"category": "Internal reference", 

"to ids":false, 
"uuid":"5f4612d7-xxxx-xxxx-xxx-6exxx020f", 
"event id":"1765565", 

"distribution":"5", 

"timestamp":" 1598427863", 
"comment":"Organization where the XL-SIEM Agent has been deployed", 
"sharing group id":"O", 

"deleted" false, 

"disable correlation":true, 

"object id":"O", 

"object. relation":null, 

"yalue":" ATOS", 

"Galaxy":[ 


l, 
"Shadow Attribute":[ 


"id":"507305", 
"type":"other", 

"category": "Other", 

"to ids":false, 
"uuid":"5f4612d7-xxxx-xxxx-xxxx-6e0xxx20f", 
"event id":"1765565", 
"distribution":"5", 
"timestamp":" 1598427863", 
"comment": "Userdatal ", 
"sharing group id":"O", 
"deleted" false, 

"disable correlation":true, 
"object id":"O", 

"object. relation":null, 
"value":"SURICATA", 
"Galaxy":[ 
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l, 
"Shadow Attribute":[ 


"id":"507306", 

"type":"other", 

"category": "Other", 

"to ids":false, 

"uuid":" 5fAxx2d7-xxxx-xxx-xxx-6e060xxx020f", 
"event id":"1765565", 

"distribution":"5", 

"timestamp":" 1598427863", 

"comment":"Userdata2", 

"sharing group id":"O", 

"deleted" false, 

"disable correlation":true, 

"object id":"O", 

"object. relation":null, 

"value":"Denial of service event detected by Suricata", 
"Galaxy":[ 

|; 
"ShadowAttribute":[ 


} 
l, 
"ShadowAttribute":[ 


1 
"RelatedEvent":[ 


] 


1 
"Object":[ 
l, 
"Tag":[ 
{ 

"id":"18", 

"name":"xl-siem:category=\"info\"", 

"colour":"#3a0a00", 

"exportable":true, 

"hide_tag":false, 

"user_id":"0", 

"numerical_value":null 


Galaxy":[ 


"id":"57", 
"name":"xl-siem:sub-category=\"misc\"", 
"colour":"#571000", 

"exportable":true, 

"hide_tag":false, 

"user_id":"0", 

"numerical_value":null 
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3.3.1.6 | Controller to Dash Interface 


| Name: CONT-DASH 
Description 


| Component 

_ the interface 

| Consumer components 
| or External Entities 
Type of Interface 

Input data / Output Data 


providing 


Constraints / Comments 


Responsibilities 


This interface aims to define the interaction between the S-RAF dashboard and 
the S-RAF controller residing at the backend. This REST interface enables a variety 
of actions for controlling the risk assessment workflow. 


S-RAF controller 


Dashboard 


REST 


Methods or endpoints of 


the interface 
* 


Parameters of the 


method 


Return Object or Values 


_ of the method 


* S-RAF controllers includes all REST interfaces required for the rendering of the 
Ul in the dashboard, and facilitate the interaction with the other components and 
the repository related functions. Not provided in detail due to space and privacy 


limitations. 


| UBI 


Table 7: Details of the CONT-DASH Interface 


3.3.1.7 Risk Level Assessment Interface to Controller 


Name: RLA-CONT 
Description 


Component 
the interface 
| Consumer components 
| or External Entities 

| Type of Interface 

| Input data / Output Data 


providing 


This interface aims to define the interaction between the Risk Level Assessment 
Component and the S-RAF controller. This is an internal interface that enables 
the triggering of the risk assessment process. 
Risk Level Assessment Component 


| S-RAF Controller 


REST 

Methods or endpoints of 
the interface 
POST 

/api/v1/riskassessment 
DELETE 

/api/v1/riskassessment 


POST 
/api/v1/riskassessment/{ 
id} /execute 

POST 
/api/v1/riskassessment/{ 
id}/asset/{aid}/threat/{ti 
d} 

POST 
/api/v1/riskassessment/{ 
id}/asset/{aid}/threat/{ti 
di 

POST 
/api/v1/riskassessment/ 


Parameters of the 


method 


Risk assessment id 


Risk assessment id 


Risk assessment id, asset 


id 


Risk assessment id, asset 
id, thread id 


Risk assessment id, asset 
id, vulnerability id 


_ of the method 


Return Object or Values 
Risk assessment id — 
Html Response Code 


Json object with risk 


assessment 


Html Response Code 


Html Response Code 


Html Response Code 
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{id}/asset/{aid}/vulnerab | 
_ility/{vid} | 
POST Risk assessment id, asset | Html Response Code 
/api/v1/riskassessment/ id, control id 
/{id}/asset/{aid}/control/ 
Acid) | 
POST Risk assessment id, asset Html Response Code 
/api/v1/riskassessment/ id, vulnerability id 
/{id}/asset/{aid}/vulnera 


bility/{vid} | ue 
Constraints / Comments | Main functions were presented 
Responsibilities UBI 


Table 8: Details of the RLA-CONT Interface 


3.3.1.8 Impact Analysis to Risk Level Assessment Interface 

Description This interface aims to define the interaction between the Impact Analysis 
Component and the Risk Level Assessment Component. This is an internal 
interface that enables the triggering of the risk assessment process given the | 

analysis performed on the impact of identified threats and vulnerabilities. | 

Component providing Impact Analysis Component 

the interface u m BEEN 

Consumer components Risk Level Assessment Component 

or External Entities 


Type of Interface  REST | | 
Input data / Output Data Methods or endpointsof Parameters of the Return Object or Values 
the interface method | of the method 
POST Risk assessment id Json with Attack path 


/api/v1/riskassessment/ 
/{id}/discoverattackpath | 
S 
POST Risk assessment id — Json with Attack path 
/api/v1/riskassessment/ 
| EM . / (id]/analyzeattackpaths 
Constraints / Comments - _ 
Responsibilities .. UBI 


Table 9: Details of the IMP-RLA Interface 


3.3.1.9 Assets Identification to Impact Analysis 
Description This interface aims to define the interaction between the Asset Identification 
component and the Impact Analysis Component. This is an internal interface that 
enables the impact analysis to consider the interdependencies of assets in order 
_ to calculate the impact of cascading effects on asset chains. 
Component providing Assets Identification 
the interface 
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Consumer components Impact Analysis Component 
_ or External Entities | Zu 
Type of Interface = = = Java Method . |. | 
Input data) Output Data Methods or endpoints of Parameters of the Return Object or Values 
the interface method _ of the method 
. RetrieveAssets Asset List of Assets 
Constraints - 


Responsibilities | UBI 
Table 10: Details of the ASI-IMPInterface 


3.4 Behavioural View 
The planned integration with S-RAF components was initially defined in deliverable D2.3 [4], and is 
presented in Figure 10 below. 


S-RAF Behaviour. Security Alerts Processing. 


Risk Level | | Vulnerabilities 
Assesment Manager 


1 
Security Alert ! 
informs about involved assets | 


Get vulnerabilities info. 
(per asset) 


Vulnerabilities info. || 


Risks level 


1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
! categorization (per asset) 
1 


[Only if severity level exceeds a threshold] 


Record in ARIEC 


Record Incident 
in ARIEC 


Generate Report 


| LI | | 

|| | | || 
Risk Level Vulnerabilities 
Assesment Manager 


www.websequencediagrams.com 


Figure 10: S-RAF basic behaviour as defined in D2.3 


Based on the work performed since D2.3 and the more precise definition of the components of S-RAF 
and interaction between them and also the interaction with the external components, as presented in 
sections 3.3, we provide the detailed interaction on basic risk assessment scenarios. As can be seen 
also from the scenarios that are presented below, although the triggering event for assessing the risk 
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may differ, the impact analysis components requires and updated vievv on the vulnerabilities, the 
threats and the assets vvith their interdependencies. 


For example, Figure 11 depicts the sequence of events that happens when a new asset is discovered 
or an existing is edited. 


Asset Threat Vulnerability 
S-RAF Identification Identification Management Impact Analysis Risk Level 
AIDB | | XL-SIEM/CI Dashboard Controller Component Component Component Component Assessment Component | KAFKA | 


' 
- New asset Discovery 
1 
' 

i 

' 

Retrive Assets 

Assets 


i 
| 
D 
D 
D 
D 
D 
D 
D 
D 
D 
| 
i 
D 
D 
D 
D 
| 
' 
D 
D 
' 
D 
pe 
D 
D 
D 
D 
D 
|| 
i 
D 
D 
D 
D 
|| 
D 
| 
D 
' 
i 
|| 
D 


[1 [1 
AIDB | | XL-SIEM/CI Dashboard S-RAF Asset Threat Vulnerability Impact Analysis Risk Level | KAFKA | 
Controller Identification Identification Management Component Assessment Component 


Component Component Component 


Figure 11: Detailed Sequence diagram of S-RAF — New asset discovery scenario 


In a similar manner, Figure 12 depicts the sequence of events that happens when a new vulnerability 
is discovered in an asset. 
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Asset Threat Vulnerability 
S-RAF Identification identification Management Impact Analysis Risk Level 
= 


Retrieve Assets 


|| 
| sa ELE IE ee, 


E C 
AIDB | | xL-siem/cis ||| Dashboard I| s-RAF Asset Threat Vulnerability || | Impact Analysis Risk Level | KAFKA | 
Controller Identification Identification Management Component Assessment Component 


Component Component Component 


Figure 12: Detailed Sequence diagram of S-RAF — New vulnerability discovery scenario 


When a vulnerability is patched, risk must be re-assessed as depicted in the sequence diagram of Figure 
13. 


(0 SDN microSENSE consortium Page | 47 
Public document 


SDN-uSense 
D3.5 
Version 1.0 


Impact Analysi Risk Level 
Component Assessment Component 


Asset Threat Vulnerability 
Identification Identification Management 
[aioe | XL- | XL-SIEM/CIS | [| peshboara]] ES Component Component Component 


1 

i 1 E 1 1 1 
LI 1 1 1 1 1 
1 i 1 i Jj 1 
' 1 ' i i ' 
' 1 ' i i 1 i 
' i i 4 i || i 
' | ' i i 1 ' 
' 1] ' i i i i 
' i ' 4 i i ' 
i i | i Check if vulnerability is patched! i | | i | 
' [ ' i | i i ' 
' i ' i i i i i ' 
! H ! | Check for asset changes > H ! D | ! 
' i ' ' i i i i i 
| Retrieve Assets I ! 1 k H 1 ! 
i 1 i 1 i i i 1 i 
Assets_ ERN — ——— — » i i i i i 

' i i ' 
i i i i Discover changes | i i i i 
' [| i ' i i i 1 i 
' | i ' i ' i 1 i 
' 1 i ' i i 1 i i 
A : ! New asset notification l ; 4 ! t 
| i i i Init threat discovery | i i i i 
1 1 1 + 1 1 1 1 
i |. Retrieye Events i i i i i 
LI < - 1 1 || 1 
LI 1 1 1 1 1 1 1 
' ! Events ' 1 1 || 1 || 
' rc RE goce) a du || 1 D || 
i i i |, Events i i i i 
i i i < i i i 
i i i | Init impact analysis i i i 
i i ' i ' 
i i j i f Discover attack paths | ! 
i i i i i k i i 
i i i i i Init risk assessment i i 
' i ' i i i 
i i i | i | Risk output i 
1 1 1 |j D |... LÉ  — 
i i »- Risk output | i i i 
' i T T 1 ' 

[aie | | XL-SIEM/CIS | | Dashboard | Asset Threat Vulnerability Impact Analysis Risk Level 
Es Identification Identification Management Component Assessment Component 
Component Component Component 


Figure 13: Detailed Sequence diagram of S-RAF — Re-assessment of risk scenario 


Finally, Figure 14 depicts the sequence of events that happens when a new alarm is provided by XL- 
SIEM. 


S-RAF 


Asset Threat Vulnerability 
Identification Identification Management 


Component Component Component 


S-RAF 
Dashboard Controller 
1 


1 1 1 
- - - New vulnerability discovery on existi = 
1 
1 1 1 1 1 | 1 
| | Init evul | = ! | 
1 1 1 1 LI 1 1 
! [ ' Vulnerabilities i 1 i A 
[ TT, E eM 4 ' 1 
1 1 1 1 1 D 1 
| ! 1 Init threat discove >! ! i i 
D . I || || || [ || 
P Retrieye Events y j u ! ! 
1 1 ^ || 1 1 
KE Nah pu ; | ; 
i 1 Events i i i 1 
1 1 1 D 
t | Init impact analysi i ' | i 
1 U T T 1 1 
i : i $ Discover attack paths | 1 
1 1 1 1 ESI $ 1 
1 D 1 1 || D 
i i i i Init risk assessment 1 i 
i i i i i 
1 D || 1 1 
1 1 1 1 1 
i Risk output M i i i 
1 1 1 D 1 
Dashboard S-RAF Asset Threat Vulnerability Impact Analysis 
Controller Identification Identification Management Component 
Component Component Component 


Figure 14: Detailed Sequence diagram of S-RAF — Risk assessment due to alarm from XL-SIEM 
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4 SDN-microSENSE Risk Assessment Framework Implementation 


Details 


In this section some insights about the implementation of S-RAF are provided, by presenting 
information on the database schemas, used technologies and the compilation process. In addition, the 
implementation of the risk assessment calculation is described. Again, it has to be noted that no 
restricted data of the platform will be provided; the goal however of this section is to provide the 
reader a better understanding of the developed solution. 


4.1 Technologies and Standards 

For the implementation of S-RAF, UBITECH's OLISTIC Risk Assessment Framework has been used, so S- 
RAF has been built using Java 8 and Spring Boot Framework, while for the dashboard, Thymeleaf [12] 
template engine and has been used. For the storage, both a relational database (MySQL) and a 
document-oriented database (MongoDB) are utilized. The asset modelling component uses Neo4j [11] 
for the realisation of the interdependency graphs. 


In addition, for enabling interoperability with other tools of the SDN-microSENSE architecture, S-RAF 
is compatible with open standards for threat information sharing and handles received inputs of 
indicators of compromise under MISP format. For sharing the output of the risk assessment operation, 
S-RAF integrates Apache KAFKA [13] to realise a publish/subscribe model and ease the integration with 
tools that could take advantage of the risk assessment output (e.g., SDN-SELF components). 


As presented in Section 3, S-RAF also includes eVUL, a tool owned by AYESA, and is part of the GridPilot 
platform of AYESA. eVUL uses Java, PostgreSQL [14], REDIS [15] and Neo4j [11]. 


For the easier deployment of S-RAF components Docker can been used. 


4.2  S-RAF Implementation 

This section offers implementation details for S-RAF. S-RAF extends UBITECH's OLISTIC Risk Assessment 
Framework and integrates the eVul tool to enable vulnerability management. The reader can refer to 
section 2.3.2 to have an overview of the notable extensions of OLISTIC in the context of SDN- 
microSENSE. 


S-RAF acts as an intermediate entity between the tools that aim to detect and log cybersecurity events 
against the SDN-microSENSE infrastructure, and tools that undertake self-healing actions to increase 
the resilience of the SDN-based Energy Ecosystem. Having said that, S-RAF utilises several models of 
storing input information and feed the risk assessment operation. That is, section 4.2.2 provides an 
overview of the database schema used in S-RAF that reveals the core entities and the corresponding 
relations. 


In addition, S-RAF exposes a REST interface for enabling the communication between the S-RAF 
dashboard and the backend components. Section 4.2.1 exposes the code structure of S-RAF and offers 
an overview of the REST controllers used for supporting the risk assessment workflow. Finally, the 
section details on the compilation and deployment process of S-RAF components, including the 
deployment of Apache KAFKA which is used as an integration point for tools that exploit the output of 
the risk assessment process. 
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4.2.1 Packaging and Code structure 
In this section we present an overview of the code structure of S-RAF, and provide a mapping to the 
architectural subcomponents as explained in section 3. In Figure 15, the packaging of S-RAF is depicted. 


> db-init 
> docker-containers 
> frontend 


> nist 


> reporting 


> repository 

> rest-api 

> rpc 

> util 

> utility-scripts 
gitignore 
docker-compose.yml 
Dockerfile 
openvas.crt 
pom.xml 

@ README.md 


Figure 15: Packaging of S-RAF code 


These folders include mainly the code of OLISTIC that is used and adapted for the scope of SDN- 
microSENSE, docker containers for any additional service needed, such as databases (MySQL, Mongo 
and Neo4j Graph database), eVul and Kafka. All the services and S-RAF are deployable with the same 
docker compose file (see Annex | — Docker Compose for S-RAF installation). It the following Figure 16, 
the code modules of the core application of S-RAF is presented. 
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project xmlns= xmins:xsi- 
xsi: schemaLocation= 


modelVersion»4.0.0«/modelVersion 
groupId»io.sraf«/groupId 
artifactId>parent</artifactId 
packaging>pom</packaging 
version>@.1.@-SNAPSHOT</version 
name>sraf</name 

url>http: //www.sdnmicrosense.eu/</url 
description>S-RAF Components</description 


parent 
groupId»org.springframework.boot:«/groupId 
artifactId>spring-boot-starter-parent</artifactid 
version>1.5.6.RELEASE</version 
relativePath 
parent 


modules 


module>api</module 
module>util</module 
module>reporting</module 


module>repository</module 


module>rest-api</module 


module>rpc</module 


module >app</module 


module>frontend</module 


module>nist</module 
modules 


Figure 16: Software modules as part of the main .pom file of S-RAF 


The “api”, “util”, and “reporting” modules are providing the backbone part of the module “app” that 
builds the whole backend of the S-RAF application (and includes classes for the Assets Identification, 
Threat Identification, Impact Analysis, Risk Level Assessment components in relation to Figure 7 that 
presented the conceptual architecture of S-RAF). Updates were made on all the modules, with the 
most important for the scope of the deliverable being the implementation of the cumulative risk 
assessment logic, as presented in section 4.5.1.2. The “repository” module includes the data access 
layer of S-RAF to the databases (MySQL, MongoDB, Neo4j). The final part of the backend of S-RAF is 
the "rest-api" and the "rpc" modules. For the context of S-RAF updates were made only to the "rest- 
api" part as we currently didn't need to extend any rpc based communication. Finally, the "frontend" 
module is responsible for building the actual dashboard of S-RAF. 


4.2.2 Data Model Highlights 

In the following part of the deliverable we provide an overview of some parts of the relational 
database, with the purpose of assisting the user to understand the way that the risk assessment is 
performed. Firstly, in Figure 17 we present the assets as defined in the S-RAF. 
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assetid BIGINT (20) 
tepid BIGINT(20)_| 


* id BIGINT(20) 

? assettypeid BIGINT (20) 

2 productid BIGINT (20) 

9 threatid BIGINT (20) 

* vulnerabilityid VARCHAR(255) 
9 assetid BIGINT (20) 


* id BIGINT(20) 
^» relationshiptype VARCHAR(255) 
@relatedassetid BIGINT(20) —— 


> 


* id BIGINT (20) 


| 
I 
I 
| 
I 
I 
I 
| 
I 
I 


* id BIGINT (20) © assetcost VARCHAR(255) 

© name VARCHAR(64) |__| Vassettype VARGIRESS) [| 
© assetypechainname VARCHAR(256) © cpe22name VARCHAR(255) 

© cyberrequired BIT(1) SS i © name VARCHAR(128) 

© gpdrallowed BIT(1) | © runprivilege VARCHAR(255) 

© editor VARCHAR(255) [aa — 4< #businesspartnerid BIGINT (20) 


© fadn VARCHAR(256) 
Q ipaddress VARCHAR(256) 
9 assetcategoryid BIGINT (20) 
^? assetstatus VARCHAR(255) 
2 importcode VARCHAR(255) 
^? importidentifier VARCHAR(255) 


2 parentassetypeid BIGINT (20) 
assetypeid BIGINT(20) 


processid BIGINT (20) 
assetid BIGINT (20) 


# id BIGINT(20) 
‘9 name VARCHAR(255) 

^ isdefault BIT(1) 

® businesspartnerid BIGINT (20) 


assetid BIGINT (20) 
controldescriptorid BIGINT(20) 


> 


Figure 17: Assets Representation 


Assets are the core concept of S-RAF risk assessment as everything that needs to be included in the 
risk assessment calculation can be defined as an asset. It has to be noted that for the definition of 
assets and their dependencies with the goal of creating the assets’ graph, the Neo4j graph database is 
used due to its faster and more efficient finding of the attack paths and its integrated visual graph 
support. 


In Figure 18 the threats definition as part of the S-RAF model is presented. 


Lul 


? id BIGINT (20) 
name VARCHAR(128) 


* id BIGINT (20) 
© probability VARCHAR(255) 
9 threatid BIGINT (20) 


* id BIGINT(20) 

^^ name VARCHAR(255) 

9 isdefault BIT(1) 

kd. businesspartnerid BIGINT (20) 


© description VARCHAR(1024) 
© identifier VARCHAR(16) 
©iscustom BIT(1) 
^^ name VARCHAR(128) 
2 businesspartnerid BIGINT (20) 
2 libraryd BIGINT(2D) 
> 


* id BIGINT (20) 
name VARCHAR (64) 
> 


Figure 18: Threats Representation 
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Vulnerabilities are defined in detail through the dedicated table in the relational database, as 
presented in Figure 19. 


? id VARCHAR(255) 
© accesscomplexity VARCHAR(255) 
 accessvector VARCHAR(255) 


© authentication VARCHAR(255) pl—— 


= availabilityimpact VARCHAR(255) 

© confidentialityimpact V ARCHAR(255) 
© cvssscore DECIMAL(19,2) 
 exploitabilityscore DECIMAL (19,2) 
impactscore DECIMAL( 19,2) 

© integrityim pact VARCHAR(255) 
iscon firmed BIT(1) 

© legalimpact VARCHAR(255) 
isegal BIT(1) 

© legalavailabilityimpact VARCHAR(255) 
© legalconfidentialityimpact VARCHAR(255) 
© legalintegrityimpact VARCHAR(255) 

? libraryid BIGINT(20) 

© modified DATETIME 

= published DATETIME 

© description LONGTEXT 

© protection V ARCHAR(255) 


> 


* id BIGINT (20) 
© name VARCHAR(128) 


vulnerabilityid VARCHAR(255) 
assettypeid BIGINT (20) 


vulnerabilityid VARCHAR(255) 
comm onweaknessid VARCHAR(255) | 


m 


Figure 19: Vulnerabilities Representation 


vulnerabilityid VARCHAR(255) 
productid BIGINT (20) 


Finally, for the calculation of the risk assessment, S-RAF uses scenarios, that include the assets, the 
threats and the vulnerabilities, as depicted in Figure 20. 


* id BIGINT (20) 


© completion INT(11) 


* id BIGINT(20) 


© datecreated TIMESTAMP 

9 name VARCHAR(128) 

© riskassessment_status VARCHAR(255) 
2 riskassessment_type VARCHAR(255) 
9 initiatorbusinesspartnerid BIGINT (20) 
9 processid BIGINT (20) 

© dateexecuted TIMESTAMP 


© datecom pleted TIMESTAMP 


* id BIGINT (20) 
© name VARCHAR(64) 


* id BIGINT(20) 


* id BIGINT (20) 

© assetcost V ARCHAR(255) 

^^ assettype VARCHAR(255) 

© cpe22name V ARCHAR(255) 

^? name VARCHAR(128) 

© runprivilege VARCHAR(255) 
—4< ® businesspartnerid BIGINT (20) 
© fadn VARCHAR(256) 

© ipaddress VARCHAR(256) 

9 assetcategoryid BIGINT (20) 
© assetstatus VARCHAR(255) 

© importcode VARCHAR(255) 

“ importidentifier VARCHAR(255) 


* id BIGINT(20) 

2 assettypeid BIGINT (20) 
? productid BIGINT (20) 

$ threatid BIGINT (20) 


9 vulnerabilityid VARCHAR(255) 


© assetid BIGINT (20) 


9 description VARCHAR(1024) 


identifier VARCHAR(16) 


^ iscustom BIT (1) 


$ id VARCHAR(255) 

© accesscomplexity VARCHAR(255) 

^? accessvector VARCHAR(255) 

© authentication VARCHAR(255) 

© availabilitympact VARCHAR(255) 

© confidentialityimpact V ARCHAR(255) 
© cvssscore DECIMAL(19,2) 

© exploitabilityscore DECIMAL (19,2) 

© impactscore DECIMAL( 19,2) 

© integrityim pact VARCHAR(255) 
Sisconfirmed BIT(1) 

© legalimpact VARCHAR(255) 

isegal BIT(1) 

© legalavailabilityimpact VARCHAR(255) 
© legalconfidentialityimpact VARCHAR (255) 
© legalintegrityimpact VARCHAR(255) 
2 libraryid BIGINT(20) 

© modified DATETIME 

© published DATETIME 

© description LONGTEXT 

© protection VARCHAR(255) 


9 name VARCHAR(255) 
© isdefault BIT(1) 
® businesspartnerid BIGINT (20) 


© name VARCHAR(128) 
2 businesspartnerid BIGINT (20) 
? libraryid BIGINT(20) 


> 
699 SQ i 


Figure 20: Representation of Scenarios for Risk Assessment in EPES for S-RAF 
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4.3 Compilation Process 
4.3.1 Prerequisites 


This project is written in Java and Apache Maven can be used for the compilation of the code, thus 
allowing library dependencies to be imported automatically, through the following command. 


mvn clean compile 


4.4 Deployment Process 

S-RAF components are built as docker images and therefore can be deployed together with their 
dependencies (databases, Kafka queue, etc) through the usage of docker compose files. This part is 
described in section 5.1. 


4.5 Risk Assessment Process Description 

The Risk Assessment process undertakes the task of calculating the final risk scores based on the 
evidences collected from the various input sources of S-RAF. While D3.2 [3] provided the SDN- 
microSENSE Risk Assessment meta-model, including the risk calculation approaches, this section 
focuses on implementation aspects for exploiting the acquired inputs and deriving the final risks. 


The risk assessment methodology is based on the following specific notation and considers a set of 
assumptions, especially for the case of cumulative risk calculation. In the following paragraphs we 
provide a set of key characteristics of the risk assessment methodology, which are important for 
grasping the rational of the risk calculation. 


e The EPES ecosystem consists of interrelated assets Aj, ..., A, which are interconnected with 
each other based on their dependency. So far, in the SDN-microSENSE methodology the 
following interdependencies have been identified: IsInstalledOn, IsLocatedIn, IsConnectedTo, 
IsUsedBy, IsProcessedBy and IsStoredOn. Thus, the assets form a graph or network, namely 
the interdependency graph, where the assets are represented by the nodes and the 
interconnections among them are represented by the edges. 

e Each asset Aj may have several vulnerabilities Va. 1, ..., Va, n,- Hence, the network of assets can 
further be transformed in a graph, where the nodes are combinations of assets and 
vulnerabilities. The vulnerabilities for each asset can be found with the help of specific 
software. In our case, this task is undertaken by eVul. The information of eVul is integrated 
with the assets’ information in the context of the vulnerability identification component of S- 
RAF. 

e Each asset/vulnerability pair VA,j has two core characteristics (among others), which are 
important for further computation: one describing the Individual Vulnerability Level (IVL) 
IVL(Va,;) and the other one describing the Impact Level I(V4,;). These two characteristics 
are based on specific values coming from the Common Vulnerability Scoring System (CVSS) 
and they describe the severity of a vulnerability. For our further analysis, the interested reader 
can refer to D3.2 [3]. 


After defining some fundamental notions for the risk assessment approach, the following sections 
elaborate on the calculation of the two risk variants, namely the individual and the cumulative risks. 
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4.5.1 Risk Calculation 

We will rely on qualitative values for representing the risk levels and the general Impact Level of a 
vulnerability (in terms of the three standard security criteria Confidentiality, Integrity and Availability). 
Similarly, we will use a semi-quantitative scale for the probability that a vulnerability is exploited by a 
specific attacker. To make the handling easier, we are using a five-tier scale for all three applications 
and will use this five-tier scale throughout the SDN-microSENSE methodology. These five categories 
are ranging from 


e “Very Low" (VL) 
e "Low" (L) 

e “Moderate” (M) 
e “High” (H) 

e “Very High" (VH). 


4.5.1.1 Individual Risk Calculation 

The Individual Risk Level (IRL) represents how dangerous a threat is to the specific asset within EPES. 
More specifically, IRL quantifies the risk of an asset taking into consideration all the associated 
vulnerabilities ignoring the assets dependencies and relationships. The IRL can be calculated as a 
multiplication of the imposed Threat level (TL), Individual Vulnerability and Impact Levels (IVL and IIL, 
respectively) as follows: 


IRL = TL X IVL X IIL 


More details on the calculation methods of the factor of the abovementioned formula are given in 
D3.2 [3]. 


4.5.1.2 | Cumulative Risk Calculation 

The Cumulative Risk Level (CRL) refers to the risk level imposed to an asset (a target point), as a result 
of a vulnerability exploitation, given a threat, to an entry asset. The cumulative risk level can be derived 
if there is a path that connects the entry asset to the target asset. In other words, CRL quantifies the 
risk that is caused on a single asset using the vulnerability profiles of the adjacent assets taking into 
consideration all the possible attack paths that are generated towards this specific asset. The 
cumulative risk represents how dangerous a threat is to the specific asset and can be calculated as a 
multiply of threat level (TL), cumulative vulnerability level (CVL) and cumulative impact (CIL) as follows: 


CRL = TL x CVL x CIL 


More details on the calculation methods of the factors of the abovementioned formula are given in 
D3.2 [3]. 


Application of the Attacker Profile 


In order to be able to materialize the cumulative methodology, it is vital to document the conditions 
under which an attacker can propagate in a network by exploiting vulnerabilities. In the Cumulative 
Risk Assessment methodology, the Cumulative Vulnerability Level (CVL) of an asset/vulnerability 
combination heavily relies on the attacker profile, i.e., the skills and characteristics the analyst grants 
the attacker in a specific risk assessment. Only by using the information coming from this specific 
attacker profile, we will be able to make some estimation on the probability, that a vulnerability can 
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be exploited. An attacker has two main properties: the capability (if the attacker is skilled or just an 
amateur) and his location (if he is attacking from the outside or from the inside). 


The attacker’s location can be used to reduce the number of potential entry points, since an outside 
attacker can just attack assets/vulnerability combinations with a CVSS Access Vector “Network”, as 
already explained in D3.2 [3]. We will assume that if the Access Vector is “Adjacent” or “Local”, an 
attacker from the outside will not be able to exploit this vulnerability. 


In the context of SDN-microSENSE, due to the high criticality of the infrastructure aimed to be 
protected, we consider attackers that have “High” and “Very High” level of expertise. By considering 
these levels of expertise, the overall risk assessment framework adopts a rather risk-averse approach 
that, on the one hand may require a more intense engagement on behalf of risk assessors, but on the 
other, guarantees that risks corresponding to propagated threats become the focal point of the 
analysis. Although a detailed analysis on the attacker types have been conducted in D3.2 [3], Table 11 
offers a summary of the characteristics of high-skilled attackers according to NIST. We consider that 
these attacker types have the expertise and the technical means to exploit potential vulnerabilities on 
SDN-microSENSE architectural assets. 


Qualitat Description of the Description of the Attacker’s Intent Description of the Attacker’s 


ive Attacker's Capability Targeting 


NETTES 
| The adversary analyses information 
, obtained via reconnaissance and 
Theadversaryhasavery | The adversary seeks to undermine, E 
a é attacks to target persistently a 
sophisticated level of severely impede, or destroy a core Në UAM . 
| ^ . Pm ; ; specific organization, enterprise, 
expertise, is well- | mission or business function, program, or OA K 
É MA . program, mission or business 
Very resourced, and can enterprise by exploiting a presence in the ^ É M o 
: e EPA ae | function, focusing on specific high- 
High generate opportunities | organization’s information systems or ER Mn: N 
A ë ; value or mission-critical information, 
(VH) to support multiple infrastructure. The adversary is i 
A N resources, supply flovvs, or functions: 
successful, continuous, concerned about disclosure of tradecraft t su 
; ; r R specific employees or positions; 
and coordinated | only to the extent that it would impede its À í 
| Ki supporting infrastructure 
| attacks. ability to complete stated goals. 4 : ; 
providers/suppliers; or partnering 
| | organizations. 
The adversary seeks to 


undermine/impede critical aspects of a | The adversary analyses information 
The adversary has a | core mission or business function, | obtained via reconnaissance to target 
sophisticated level of | program, or enterprise, or place itself in a | persistently a specific organization, 


expertise, with | position to do so in the future, by | enterprise, program, mission or 
High (H) significant resources | maintaining a presence in the | business function, focusing on specific 
and opportunities to | organization's information systems or | high-value or mission-critical 
support multiple | infrastructure. The adversary is very | information, resources, supply flows, 
successful coordinated | concerned about minimizing attack | or functions, specific employees 
attacks. detection/disclosure of  tradecraft, | supporting those functions, or key 
particularly while preparing for future | positions. 
attacks. 


Table 11: Description of the high skilled Attacker Types according to NIST 
Identification of Attack Paths 


Based on the attacker profile, which is chosen by the risk assessor performing a risk assessment, 
according to his domain knowledge and the current security status of the infrastructure, several attack 
paths can be computed based on the asset/vulnerability combinations and asset interrelations. 
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Given that high-skilled attackers can take advantage of vulnerabilities on assets, the propagation of an 
attack in a network depends to the vulnerability types per se. Thus, a vulnerability that enables 
propagation generates a new pivot for the attacker and, consequently, a new edge in an attack path. 
Having said that, it becomes obvious that the generation of a new edge depends on the type of the 
vulnerability and the type of the interdependence between the related assets. For instance, if the 
"installed on" dependency associates a service and an operating system (i.e. the service is 
"installed on" the operating system), the existence of a vulnerability that enables privilege escalation 
on the operating system generates a pivot to compromising the service. In this direction, attacks 
propagated through the network require the existence of a "connected to" relation to realise new 
edges in the pats. Based on the above, we consider that the formation of attack paths, due to cyber 
security vulnerabilities, require the existence of "connected to" and "installed on" relations among 
the assets and a type of vulnerability that enables the exploitation of this relation. Our implementation 
traverses the assets interdependency graph and using the information on the attacker, the 
vulnerabilities and the relations, a set of attack paths is returned. These paths represent the potential 
ways through the graph from a given Entry Point to a specific Target Point. These attack paths are 
required to compute the CVL. 


In general, the number of potential paths from the Entry Point to the Target Point grows exponentially 
with the size of the graph. Due to the restrictions we obtain from the attacker's location and intention, 
the number of potential paths is reduced such that a computation stays feasible. 


The code snippets given in the following figures reveal part of the implementation details of core 
functions. The discovery of attack paths and calculations, in the context of Attack Path Analysis Service, 
over the probabilities for vulnerability exploitation in the cumulative risk assessment approach are 
given in Figure 21: Code snippet for attack path Identification in Attack Path Analysis Service and Figure 
22. 


More specifically, Figure 21: Code snippet for attack path Identification in Attack Path Analysis Service 
presents the method used for traversing an attack path considering an attacker with very high skills, in 
order to calculate the probability of an attacker exploiting this path. 


© SDN microSENSE consortium Page | 57 
Public document 


SDN-uSense 


D3.5. 
Version 1.0 


@Override 


public Map<ProbabilityScale, Long> attackPathHistogram(AttackPath attackpath, 
AttackPathAnalysis attackpathanalysis) { 


Map<String, Object» parameters = new HashMap<String, Object>(); 
parameters.put("riskassessmentId", attackpathanalysis.getRiskassessmentid()); 
parameters.put("sssetId", attackpath.getNodes().stream().filter(n -> n.getAssetid().startsWith("s")) 


-map(n -> Long.valueOf (n.getAssetid().substring(i))).collect(Collectors.toSet())); 


Map<Long, RiskassessmentRunAsset> rrassetmap = PagingUtility 


-mongoAggregationPageable (mongoTemplate, parameters, new PageRequest (0, Integer.MAX VALUE), 
new String[] { "assetId", "name", "type", "cpe22name", "risklevel", "threats" }, 
new String[] {}, RiskassessmentRunAsset.class, RiskassessmentRunAsset.class) 

-getContent().stream().filter(a -> a.getThreats().size() > 9) 

-collect (Collectors .toMap (RiskassessmentRunAsset::getAssetid, Function.identity())); 


Iterator<AttackPathNode> attackPathNodelterator = attackpath.getNodes() .iterator(); 


final AttackerCapability attackerCapability = (attackpathanalysis.getConfiguration() .getAttackerCapability() != null) 
? attackpathanalysis.getConfiguration().getAttackerCapability() 
: AttackerCapability.VH; 
double[] pathProbabilitiesMatrix = new double[] { ld }; 
while (attackPathNodeIterator.hasNext()) { 
AttackPathNode apn = attackPathNodeIterator.next(); 
if ('apn.isAsset()) { 


continue; 


) 


Set<RiskassessmentRunAssetThreatVulnerability> vulns = rrassetmap 
-get(Long.valueOf(apn.getAssetid().substring(i))).getThreats().stream() 
-flatMap(t -> t.getVulnerabilities().stream()).collect(Collectors.toSet()); 


final int matrixSize = vulns.size() * pathProbabilitiesMatrix.length; 
double[] temp = new double[matrixSize]; 


for (int i = 0; i < pathProbabilitiesMatrix.length; i++) ( 
int j = 0; 


for (RiskassessmentRunAssetThreatVulnerability vuln : vulns) { 
double prob = ProbabilityScale.valueOf (ChainUtils 
-CalculateAttackProbability(attackerCapability, Ranking.valueOf (vuln.getLevel())).name()) 
-getMedium() ; 
double result = prob * pathProbabilitiesMatrixlil: 
temp[vulns.size() * i + j++] = result; 


} 


pathProbabilitiesMatrix = temp; 
} 


Map<ProbabilityScale, Long” result = ProbabilityScale.defaultZeroMap() ; 
result .putAll (Arrays .stream(pathProbabilitiesMatrix) .mapToObj(d -> ProbabilityScale.getRank(d)) 
-collect (Collectors .groupingBy(Function.identity(), Collectors.counting()))); 


return result; 


Figure 21: Code snippet for attack path Identification in Attack Path Analysis Service 


Figure 22 highlights the method used for analysing the attack propagation in a cumulative manner. 
Given an entry point and target point assets, this method traverses all the possible attack paths formed 
between the two points, in order to calculate the accumulated probability used in risk calculations. 
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@Override 
public Map<ProbabilityScale, BigDecimal> accumulatedPathHistogram(long businesspartnerid, long riskassessmentid, long entrypoint, long targetpoint) { 


Map<String, Object> parameters = new HashMap<String, Object>(); 
parameters .put ("businesspartnerid", businesspartnerid) ; 


riskassessmentid) ; 
, entrypoint); 
", targetpoint) ; 


parameters .put (" 
parameters .put(" 
parameters. put (” 


List<AttackPathAnalysis> analyses = PagingUtility 
-mongoAggregationPageable (mongoTe: 
new String[] { "id", "ris 
new String[] {}, AttackPa 
.getContent () ; 


Map<ProbabilityScale,Long> accumulatedHistogram = ProbabilityScale.defaultZeroMap(); 
for (AttackPathAnalysis analysis : analyses) { 
for (AttackPath attackpath : analysis.getAttackpaths()) { 
addToProbabilityHistogram(accumulatedHistogram, this.attackPathHistogram(attackpath, analysis)); 
} 
} 


return amortizeHistogram(accumulatedHistogram) ; 


Figure 22: Code snippet for analysing attach paths in cumulative manner by the Attack Path Analysis Service 


Figure 23 depicts the java interface used to instruct the business logic and call methods for the Attack 
Path Analysis Service implementation. 


@Service 
public interface IAttackPathAnalysisService<A, AP, PAGE» { 


void save(A attackPathAnalysis); 

Optional<A> findOne(String id); 

Iterable<A> findAll(PAGE page); 

Iterable<A> findByBusinesspartneridAndRiskassessmentid(long businesspartnerid, long riskassessmentid, PAGE page); 

void delete(String id); 

Map<? extends Enum<?>, Long” attackPathHistogram(AP attackpath, A attackpathanalysis); 

List<A> findAttackPathAnalyses(long businesspartnerid, long riskassessmentid, long...riskassessmentidsToCompare); 

Map<? extends Enum<?>, BigDecimal> accumulatedPathHistogram(long businesspartnerid, long riskassessmentid, long entrypoint, long targetpoint); 


Figure 23: Code snippet of the business logic implemented by Attack Path Analysis Service 


Figure 24 depicts the function responsible for extracting the attack paths from the graph of assets and 
responding to the SRAF dashboard with a visualisation object for representing the attack paths 
between entry point assets and selected target points. The traversal of the graph of assets is done 
using the Depth-First Search (DFS) method. 
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@RequestMapping (value = "/iid)/disc P , method = RequestMethod. POST) 
public GenericSRAFRestResponse discoverattackpaths (@RequestBody AttackPathRequestDTO requestDTO) { 


final VisualizationWrapper wrapper = new VisualizationWrapper(): 
try { 
int idx = 0; 


for (Long entrypoint : requestDIO.getEntrypoints()) { 
for (Long targetpoint : requestDTO.getTargetpoints()) { 


if (requestDTO.getDisjointness()) { 


// Retrieve graph nodes for computation. 
Set<GraphNode> nodes 


Set<GraphPath> paths buildDisjointPaths(requestDTO, nodes, entrypoint, targetpoint); 


Graph graph = new Graph(constructGraphNodes (requestDTO.getRiskassessmentid(), 
AttackerCapability.valueOf(requestDTO.getAttackercapabilityrank())), "a" + entrypoint): 

graph.printStats(); 

graph.dfsPaths("s" + entrypoint, requestDTO.getMaxlength()); 

Graph.listPaths(wrapper, paths, "a" + entrypoint, idx++); 

Hgaraph.listPaths (wrapper, idx++); 


} else { 


Graph graph = new Graph (constructGraphNodes (requestDTO.getRiskassessmentid(), 


AttackerCapability.valueOf (requestDTO.getAttackercapabilityrank())), "a" + entrypoint); 
graph.printStats(); 


if (requestDTO.getPropagation()) { 


graph.dfs("2" + entrypoint, requestDTO.getMaxlength()); 
} else { 


graph.dfs("a" + entrypoint, "a" + targetpoint, requestDTO.getMaxlength()); 
} 


graph.list (wrapper, idx++); 


} 


} catch (Exception ex) { 
ex.printStackTrace(); 
Logger. getLogger (RiskAssessmentRestController.class.getName()) . severe (ex.getMessage ()) ; 


return new GenericSRAFRestResponse (BasicResponseCode.INVALID, Message.R ERROR, Optional.empty()); 
1] 


return new GenericSRAFRestResponse (BasicResponseCode.SUCCESS, Message.R AMENDED, wrapper) ; 


Figure 24: Code snippet of extracting attack paths from a graph of assets 


= constructGraphNodes (requestDTO.getRiskassessmentid(), AttackerCapability.valueOf (requestDTO.getAttackercapabilityrank())):; 


Figure 25 depicts the method responsible for analysing the attack paths and triggering the Attack Path 


Analysis Service for calculating the path risks. 
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GRequestMapping(value = "/(i s", method = RequestMethod.POST) 
public GenericSRAFRestResponse analyscActackPutlin [ÉRequssc Body ExtendedAttackPathRequestDTO requestDTO) ( 
try { 
@suppressWarnings ("serial") 


Map<String, Object> parameters = new HashMap<String, Object>() { 
{ 
put ("riskasse 
put("assetId", 
} 


", requestDTO.getRiskassessmentid()) ; 
Stream. concat (requestDIO.getEntrypoints ().stream(), requestDTO.getTargetpoints() .stream()) .collect (Collectors. toSet ())): 


IH 
Map<Long, RiskassessmentRunAsset> rrassetmap = PagingUtility 
a ai me e eng ahaaa md parameters, new PageRequest(0, Integer.MAX VALUE), 
new String[] ( “assetid”, "name"}, new String{] {}, 
RiskassessmentRunAsset.class, Mio yan enmena: class) 
.getContent ().stream() 
«collect (Collectors.toMap(RiskassessmentRunAsset::getAssetId, Function.identity())); 


for (Long entrypoint : requestDTO.getEntrypoints()) { 
for (Long targetpoint : requestDTO.getTargetpoints()) { 
Set«GraphNode» nodes = constructGraphNodes (requestDTO.getRiskassessmentid(), AttackerCapability.valueOf (requestDTO.getAttackercapabilityrank())); 
Set<GraphPath> paths = buildDisjointPaths(requestDTO, nodes, entrypoint, targetpoint);; 
AttackPathAnalysis analysis = new AttackPathAnalysis(); 
analysis.setRiskassessmentid(requestDTO.getRiskassessmentid()); 
analysis. setBusinesspartnerid (authUtil.getAuthenticatedUser() .getBusinesspartner().getId()); 
analysis.setName (requestDTO. getName () ) ; 
analysis. setCreatedate (LocalDateTime.now()); 
analysis.getConfiguration().setAttackerCapability (AttackerCapability.valueOf (requestDTO.getAttackercapabilityrank())): 
analysis.getConfiguration().setAttackerlocation(requestDTO.getAttackerlocation()); 
analysis.getConfiguration() .setEntrypointId(entrypoint) ; 
analysis.getConfiguration() .setEntrypointName (rrassetmap. get (entrypoint) .getName()); 
analysis.getConfiguration() .setTargetpointId(targetpoint) ; 
analysis.getConfiguration().setTargetpointName (rrassetmap.get (targetpoint) .getName()); 


int idx = 1 
for (GraphPath graphPath : paths) { 


AttackPath attackPath = new AttackPath(idx++, graphPath.getLength()); 


for (int i=0; i«graphPath.getLength(); i++) { 
AttackPathNode apNode = new AttackPathNode (iti, graphPath.get(i).getId(), graphPath.get(i).getName(), graphPath.get(i).getRisk()); 
attackPath.getNodes () .add (apNode) ; 
} 
analysis.getAttackpaths () .add(attackPath) ; 
} 
artackPathënalysisService. save (analysis): 
} 
} 
} catch (Exception ex) { 
ex.printStackTrace(): 
Logger. getLogger (RiskAssessmentRestController.class.getName()) .severe (ex.getMessage ()): 
return new GenericSRAFRestResponse (BasicResponseCode. INVALID, Message.R ERROR, Optional.empty()); 
} 
return new GenericSRAFRestResponse (BasicResponseCode.SUCCESS, Message.R AMENDED, Optional.empty()); 


Figure 25:Code snippet of attack path risk analysis 


4.5.1.3 Risk Profiles 

A risk profile is an evaluation of an individual's or organisation’s willingness and ability to take risks. It 
can also refer to the threats to which an organization is exposed and to the perception and the attitude 
of a security officer against risks. 


In order to incorporate this aspect in the developed assessment methodology, we capitalise on the risk 
appetite notion. According to ISO 31000 risk management standard [16], the risk appetite is defined 
as the "Amount and type of risk that an organization is prepared to pursue, retain or take". This concept 
supports an organization's decisions for risk management. 


Willingness to take on risk entails to the definition of the risk aversion. If an organization or the risk 
officer, expresses a strong desire to keep the risk at the minimum level given his/her domain 
knowledge, the security state of the infrastructure and the security awareness of the personnel, this 
person would have a low willingness to take on risk and is risk-averse. 


Given the above, in the context of SDN-microSENSE the risk profile of each organization per use case 
can be reflected in the definition of the Risk Appetite level. The risk assessment model will be in 
position to consider this factor, which may vary depending on the threats, the security state of systems, 
the security awareness of the personnel and the attitude of the risk officer of the use cases. 


The Risk appetite level will be used to regulate the final risk assessment formula by applying a 
percentage factor in the final calculation. The detailed magnitude of the risk appetite level will be 
decided per use case based on the prioritization of threats, the personnel assessment and other 
possible factors. 
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For the actual usage of the S-RAF tool for the risk assessment we provide more details in section 5.2. 


4.5.1.4 Integration with Personnel Assessment 

As explained also in D3.1 [2], company employees appear as one of the potential threat agents that 
can cause a cyber-attack. In most cases unintentionally, because of lack of training or awareness, but 
also in an intentional way (disgruntled employees), employees can put the company's assets at risk. S- 
RAF assets are not only referring to the physical infrastructures and equipment, but also covers 
information that the company manages (inventory of components, state of the network, information 
of its customers, etc.), communication networks, applications of control, databases, personal work 
devices (e.g. laptops, tablets, mobiles) and physical infrastructure. As presented in Figure 29, S-RAF 
allows adding personnel specific evaluation (e.g. Administrator), at role or at individual level, as part 
of the asset-based risk assessment. 


The level of training and awareness of employees in adopting good practices is considered an 
important input in the risk assessment process in SDN-microSENSE. Therefore, companies must include 
an evaluation process of the readiness level of their employees as part of their security procedures. 
This can be reflected through S-RAF to the overall risk appetite of the overall risk assessment, as 
depicted in Figure 33. This assigned risk appetite will be used to regulate the final risk assessment 
formula by applying a percentage factor in the final risk. 


Due to the distributed nature of the decentralized energy system, the developed methodology shall 
take into account the collaborative aspects needed by involving all stakeholders of the energy 
components. This includes mainly personnel at different places or task roles, but also include external 
stakeholders such as energy operators, consumers and energy retailers. Although there is no possibility 
to have a full evaluation as for the personnel, nevertheless stakeholders can be represented with an 
appropriate triplet of asset-vulnerability-criticality level. 


4.6 Requirements and Unit Testing Coverage 

Finally, in order to ensure the functional validity of the solution we examined the relevant 
requirements, as defined in D2.2 [1]. The following requirements presented in Table 12 have been 
covered. 


Description Coverage by S-RAF 
FR-UR-01 The system shall be able to perform a Risk assessment can be 
cybersecurity risk assessment process able performed upon 
per six months. request whenever needed. 
NFR-DPT-23 The system shall be able to handle a data Risk assessment can be 
breach, through an effective data breach | calculated both as 
management policy covering: individual risk and as 
e Containment and recovery cumulative risk 


e Assessment of ongoing risk 
e Notification of breach 
e Evaluation and response 
NFR-DPT-28 In case of testing, logical separation of Risk assessment can be 
the test site from the operational site performed in testing or 
shall be ensured, so that the risk to the operational sites. 
actual infrastructure shall be minimised 
or eliminated in case of a breach. 
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NFR-SEC-01 


NFR-SEC-02 


FR-GR-01 


For browsing web pages, the system 
shall be able to require HTTPS for all 
sensitive pages or where transmission of 
personal data takes place. Non-HTTPS 
requests to these pages should be 
redirected to the HTTPS page. Any 
included content such as images, 
JavaScript or CSS should also be provided 
over HTTPS in order to avoid 'mixed 
content' warnings in users' browsers. 
The system shall be able to employ 
HTTPS connections between all backend 
components and external systems. 

The system shall maintain an inventory 
of all the infrastructure elements with 
their exact location and their status (e.g., 
which devices are active or not, whether 
the cause is known (e.g. due to 
maintenance work) or unexpected (e.g., 
due cyber-attack or failure)). This applies 
to all types of devices, i.e. power, IT and 
OT network devices. All infrastructure 
elements shall be identified by a unique 
ID, which would be shared by the 
different databases in the system (if 


any). 


HTTPS will be used on S- 
RAF deployments for the 
demonstrators 


HTTPS will be used on S- 
RAF deployments for the 
demonstrators 

SDN-microSENSE Risk 
Assessment Framework (S- 
RAF) uses the inventory of 


the assets through the 
Assets Identification 
Component. 


Table 12: SDN-microSENSE Requirements relevant to the Risk Assessment 


In addition, deliverable D2.4 [17] defined the validation procedures for the overall platform; based on 
this strategy owners of SDN-microSENSE components should include unit tests to test specific core 


functions of the components. The unit tests defined, implemented and tested for S-RAF are provided 
in Annex Il —Unit Tests, while test related to the actual integration of SDN-microSENSE platform and 
the proper interconnections with other components, will be implemented in the Early Prototype of 
SDN-microSENSE platform, and reported in the deliverable D7.4. 
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5 SDN-microSENSE Risk Assessment Framework Adoption and Usage 
In this section we explain how S-RAF can be installed and used as a standalone service. It has to be 
mentioned that the integration process with the components of SDN-microSENSE is still to be 
performed in the scope of WP7 of the project; however, the documentation provided below can be 
valuable for the integration process and also for assisting the adoption of S-RAF and SDN-microSENSE 
by the project's demonstrators. 


5.1 Installation and Deployment 


5.1.1 Preparing the environment 
This section provides information regarding the installation of the S-RAF prototype implementation. 


5.1.1.1 Prerequisites 
For the installation a docker compose file is provided, and in an environment where Docker has already 
been installed, it can be used to easily. 


e Deploy MySQL database 

e Deploy MongoDB database 
e Deploy OpenVAS 

e Deploy eVul 

e Deploy Kafka 


All these services and components are required for the S-RAF tool to run properly. They may also be 
deployed in any other way, however the docker-compose.yml file must be consulted for the advertised 
names of the services above. 


5.1.2 Deployment 
For the first ever execution through console one must navigate to the location of the .yml file and type 
the command: 


docker-compose up -d 


This first execution shall delay a little because it pulls pre-built images from online repositories (e.g. 
Docker Hub). Although the specific docker compose will be in reality configured based on each 
demonstrator needs, the docker-compose.yml file currently used is provided in the Annex | — Docker 
Compose for S-RAF installation. 


5.1.3 Verification 
To verify that all is well one may type 


docker ps 


Apart from the actual service, three other running containers must be visible: a) the MySQL (database) 
b) the MongoDB (database) and c) the OpenVAS. 


To open their logs one may type: 
docker logs -f «container name» 


To exit the log type Ctrl+C. 
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5.1.4 Undeployment 
To stop and remove all containers one may type the command: 


docker-compose down 


5.1.5 Deployment View 
This Deployment View is intended to describe the specific components that are used in practice to 
implement the different functions described in the previous structural views presented in section 3. 


A , 
XL-EPDS SPEAR (TECN) OLISTIC Enterprise Risk 
/ CIS (ATOS) E Kafka 
Management Suite + S-RAF (UBITECH) 
= E updates (UBITECH 
XL-SIEM RAbbidMQ. icc > | 
(ATOS) (ATOS) S-RAF/XL-EPDS eVUL Honeypots Manager S-RAF/SDN- 


Interface (AYESA) (TECN) SELF Interface 


MANAGEMENT PLANE 


Figure 26: S-RAF component's deployment view 


Based on the interfaces defined and the deployment view, we highlight the fact that S-RAF will need 
to have direct communication with the RabbitMQ of ATOS to retrieve alerts and the ADAE component 
of S-RAF, through the deployed Kafka of S-RAF. All these components are part of the application plane 
and their communication is considered easily supported. For the communication with the AIDB that is 
part of the management plane we will consider the networking options more suitable per pilot 
installation. 


5.2  S-RAF Usage 

This section provides an overview of the usage workflow of the S-RAF component. The aim is to steer 
the user of S-RAF through its graphical user interface and to assist to the exploration and exploitation 
of the competitive advantages of the tool. 


5.2.1 Usage workflows 

5.2.1.1 Asset management 

Asset management is performed from the Asset Identification Component. Assets are populated from 
the Asset Identification Database (AIDB); however, S-RAF allows for asset management (e.g. add, edit 
and delete) from the UI. For instance, all the intangible Human Assets (see AST-33 from Table 13) are 
added from the UI by the security administrator. In addition, the security administrator is responsible 
to assign a Business Value to all the assets (both tangible and intangible) for the calculation of the risk. 
A snapshot of the populated (tangible) and manually added (intangible) assets are presented in the 
Figure 27 below, while in Figure 28 the UI to add a new asset is displayed. In addition, Figure 28 depicts 
all the S-RAF supported interdependencies (Relationship), the I/sinstalledOn, IsLocatedin, 
IsConnectedTo, IsUsedBy, IsProcessedBy and IsStoredOn. In D3.2 [3] three interdependency classes was 
identified (the /sinstalledOn, IsConnectedTo and IsUsedBy), but based on the SDN-microSENSE 
demonstrator analysis we further extend our classes for better representation of the 
interdependencies. Figure 29 displays the visualisation of the asset interdependencies (the asset 
interdependency graph), where each dependency is represented by the edges and each node by the 
assets. 
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Asset Management 


Name Status 


PRIVACY ASSESSMENT > Name v 


Administrator 
Programmable Logic Controller 1 
SON-enabled RTU 


SON-Switch 


Assets > Ags 


new Organizational/Personnel Asset 


Name 


Relationship 


PRIVACY ASSESSMENT — > Select an optio 


Isinstalledon 


ocatedin 


IsStoredon 


IsConnectedTo 
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Figure 27: Asset management (List) 
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Figure 28: Asset management (Add) 
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Figure 29: Asset management (Visualisation) 


5.2.1.2 Vulnerability and threat management 

Vulnerabilities are populated from the eVul tool and Threats from the XL-SIEM. Figure 30 presents a 
snapshot of the populated vulnerabilities from the eVul, while Figure 31 depicts the vulnerability 
representation in the S-RAF (e.g. the CVE-2019-14931) including the corresponding CVSS metrics. In 
D3.2 [3] we already referred to the CVSS metrics such as the Exploitability and Impact. Moreover, 
Figure 32 presents a snapshot of the populated threats from the XL-SIEM, and Figure 33 depicts the 
associated Risk appetite ragining from "Very Low" to "Very High" in each identified Threat to regulate 
the final risk assessment formula by applying a percentage factor in the final calculation. The secrutiy 
administrator is responsible to assing a specific Riks appetite per threat according to his background 
and experience. It is also possible to manage both vulnerabilities and threats from the UI. 
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Figure 30: Vulnerability management 
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Figure 31: Vulnerability management (CVE-2019-14931) 
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Figure 32: Threat management 
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Figure 33: Risk Appetite 


5.2.1.3 Risk assessment and evaluation 

At this stage all the necessary information is already added/populated in the S-RAF and the security 
administrator is responsible to create the Attack Scenarios (see Figure 34). The Attack Scenario 
represents the combination triplet among the Vulnerability, the Threat and the Asset and is performed 
in order to initiate the risk evaluation procedure. S-RAF provides two Risk variants, namely the 
Individual and Cumulative Risk Levels (IRL and CRL respectively). A general dashboard that visualizes 
all the information, including both the IRL and CRL, is presented in Figure 35, where the security 
administrator has an overview of the risk in the EPES. 


(9 SDN-ySense £ E E 


@ DASHBOARD 

Mii BUSINESS SERVICES 
ZE RISK ASSESSMENTS 
A MITIGATION LAB 

Qy DEFENSIVE STRATEGIES 


E assets 


Â PRIVACY ASSESSMENT > 


Q OPEN INTELLIGENCE v 
VENDORS 
VULNERABILITIES. 
THREATS 
CONTROLS 
ATTACK SCENARIOS 
RISK APPETITES 
Wb TAGS 
VË BULLETIN 
e$ 107 > 5 
Figure 34: Attack Scenario 
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Figure 35: Risk Assessment General Dashboard 


Vunerabiy impact 


5.2.1.3.1 Individual Risk 

The Individual Risk Level (IRL) quantifies the risk of an asset, taking into consideration all the associated 
vulnerabilities and ignoring the asset’s dependencies and relationships. Figure 36 presents a detailed 
risk assessment report for the IRL. This report includes all the assets in the graph, the associated 
vulnerabilities and the calculated IRL per asset. As can be easily identified from both Figure 36 and 
Figure 37, in the first variant of the risk assessment (IRL), three tangible assets are identified in the 
attack graph where the two of them are of Medium IRL and one of High IRL. 
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Figure 36: Individual Risk Level Report 
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Figure 37: Executive IRL Summary 


5.2.1.3.2 Cumulative Risk 

The Cumulative Risk Level (CRL) refers to the risk level imposed to an asset (a target point), as a result 
of a vulnerability exploitation, given a threat, to an entry asset. The cumulative risk level can be derived 
if there is a path that connects the entry asset to the target asset. Figure 38 displays the attack path 
representation, where the SDN-Switch is the target point and the SDN-enabled RTU is the entry point. 
By performing the second variant of risk assessment the resulting report (see Figure 39) includes only 
the assets that are included in the attack path, while the cumulative risk is calculated in the target 
point (the SDN-Switch). CRL compared with the IRL in SDN-Switch (see Figure 36 and Figure 39) 
changed from Medium to High, since it also considers the risk of the SDN-enabled RTU asset. As can 
be easily identified from both Figure 39 and Figure 40, in the second variant of the risk assessment 
(CRL), two tangible assets are identified in the attack path of High risk (one IRL - entry point and one 
CRL - target point). 
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Figure 39: Cumulative Risk Level Report 
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Figure 40: Executive CRL Summary 


5.2.1.4 Controls management 

The Mitigation Lab is the key aspect of the Controls management, where controls such as the CIS 
controls can be applied to mitigate a specific Attack Scenario. Figure 41 depicts the list of all identified 
Controls, while Figure 42 presents the Mitigation Lab, which gives the ability to manage, keep track 
and apply controls. In this way, the security administrator can manage the life cycle of the risk 
mitigation procedures and have a holistic view on the controls which have been adopted in order to 
mitigate the risks. Last but not least, the security administrator can compare (see Figure 43) how the 
applied controls affect the calculated risk and apply them accordingly. 
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Figure 41: Controls for Risk Mitigation 
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Figure 42: Assign Control to SDN-Switch 
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Figure 43: Mitigation aana 


5.2.2 Mapping between Assets, Threat and possible attack patterns 

This section documents part of the analysis conducted in the context of D3.2 [3] in order to steer S- 
RAF users in the process of assessing the cyber security risk and status of the EPES. More specifically, 
since S-RAF operations are asset-centric, it is vital to document the assets that can be included in the 
risk assessment. The SDN-microSENSE architecture is a mosaic of diverse technologies and consists of 
energy and SDN specific fields, while several mission-critical services are supported by legacy ICT 
assets. To this end, Table 13 offers a collection of assets which can be found in the EPES ecosystem 
and can be targeted by cyber security threats. It must be stated that Table 13 documents a subset of 
the assets that can be supported in S-RAF. 


Given the list of assets, the S-RAF user can refer to Table 14, where a mapping among the threats, 
possible attacks and assets is provided. This mapping can steer S-RAF user through the interaction with 
the tool and offer a focused view on the case of EPES Risk Assessment. Each attack pattern captures 
knowledge about how specific parts of an attack are designed and executed and gives guidance on 
ways to mitigate the attack's effectiveness. Attack patterns help those developing defensive 
applications to better understand the specific elements of an attack and how to stop them from 
succeeding. Following this “know your enemy” strategy, a defender can increase the robustness of the 
deployed defensive mechanisms, but more importantly is in position to identify the imposed risks and 
have proper planning for mitigating them. 


| ID Asset Description 
Assets related to the energy field 
AST-01 Smart Meter A smart meter is an electronic device that records consumption of electric energy 
and communicates the information to the electricity supplier for monitoring and 
billing. 
AST-02 Data Concentrators | An electronic device that interfaces with the sensors and transmits the obtained 
(Collectors) data to other system components. 
AST-03 Advanced Metering | The head-end system (HES), also known as meter control system, is located within 
Infrastructure (AMI) | a metering company network (Distribution System Operator - DSO) and is directly 
Head-end System communicating with the meters. 
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AST-04 


AST-05 


AST-06 


AST-07 


AST-08 


AST-09 


AST-10 


AST-11 


AST-12 


AST-13 


AST-14 


AST-15 


AST-16 


AST-17 
AST-18 


AST-19 


AST-20 


AST-21 


AST-22 
AST-23 


AST-24 


loT devices 


Programmable 
Controller (PLC) 
Remote Terminal Unit 
(RTU) 


Logic 


Intelligent Electronic 
Device (IED) 
Distributed Control 
System (DCS) 

Meter Data 
Management System 
(MDMS) 

Master Terminal Unit 
(MTU) & Human 
Machine Interface 
(HMI) 

Phasor Measurement 
Unit (PMU) 

Phasor Data 


Concentrators (PDCs) 


Control Centre / SCADA 


Distributed Energy 
Resources (DER) 
Industrial control 


system (ICS) 


Advanced 
Switch 
Microgrid Controller 
Microgrid 


Interrupting 


Controllable/Regulating 
Smart Inverter 


Automatic circuit 
recloser (ACR) 
(Recloser) 


Backup power UPS 


Billing system 
Historian 


Databases 


Smart devices, mainly in possession of the end users of the smart grid, which may 
interact with smart meters. 

Digital computer used for automation of electromechanical processes, such as 
control of machinery on industrial ecosystems. 

Microprocessor-controlled electronic device that interfaces objects in the physical 
world to a distributed control system or SCADA system by transmitting telemetry 
data to a master system, and by using messages from the master supervisory 
system to control connected objects. 

Microprocessor-based controllers of power system equipment, such as circuit 
breakers, transformers, and capacitor banks. 

System used to control a set of devices in a distributed environment. 


Software that performs long-term data storage and management for the vast 
quantities of data delivered by smart metering systems. 


A component responsible for the presentation of the data to human operators, 
usually including a console capable of monitoring and controlling the status of the 
operations. 


A device used to estimate the magnitude and phase angle of an electrical phasor 
quantity (such as voltage or current) in the electricity grid using a common time 
source for synchronization. 

Receives and time-synchronizes phasor data from multiple phasor measurement 
units (PMUs) to produce a real-time, time-aligned output data stream. A PDC can 
exchange phasor data with PDCs at other locations. 

The control centre undertakes all the monitoring and control processes. It is a 
control system consisting of computers, networked data communications and 
graphical user interfaces (GUI) for high-level process supervisory management. 
Electric generation units (including Renewable Energy: solar and wind power) 
located within the electric distribution system located close to the load they serve. 
They are parallel to the electric utility or stand-alone units. 

Command and control systems designed to support industrial processes. These 
systems are responsible for monitoring and controlling a variety of processes and 
operations such as electricity distribution. The largest subgroup of ICS is SCADA 
(Supervisory Control and Data Acquisition) systems. 

A distribution switch that can detect and interrupt faults quick and precisely. 


Devices that control and enable the establishment of Microgrids. 

Electrical systems that include multiple loads and distributed energy resources that 
can be operated in parallel with the grid or as an electrical island 

Inverter used to convert Direct Current (DC), the form of electricity produced by 
solar panels and batteries, to Alternating Current (AC). A controllable/regulating 
inverter can adjust its output to help control voltage and power factor. 

Automatic circuit reclosers (ACRs) (also known as reclosers or autoreclosers) are a 
class of switchgear which are used for distribution automation. They detect and 
interrupt momentary faults. ACRs are high voltage rated circuit breakers used as 
an overhead network distribution protection asset. 

Short period fast response auxiliary power to support a control centre’s operation 
for short power failures. 

System responsible for analysing the energy consumption data for customer billing. 
A high-capacity system designed to collect and store the logs generated by the 
readings and operations of the sensors, assets, alarms and other events generated 
by plant devices, part of the network. 


Assets related to the legacy ICT field 


Organized collection of data generally stored and accessed electronically from a 
computer system. Several databases may exist in the EPES ecosystem to server 
diverse purposes. 
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AST-25 


AST-26 


AST-27 


AST-28 


AST-29 


AST-30 


AST-31 


AST-32 


AST-33 


AST-DP 
AST-34 


AST-35 


AST-36 


AST-37 


AST-38 


AST-CP 
AST-39 


AST-40 


AST-41 


AST-AP 


AST-42 


VVLAN Access Point 


Services 


Operating system (OS) 


Applications 


Firevvall 


DHCP 


Domain Controller (DC) 


Network Components 
Human Assets 
(personnel) 


Data Plane Assets 
Programmable network 
components 


Control — Data plane 
Interface agent (CDPI 
agent) 

SDN-enabled RTUS 


SDN-enabled 
Controller 
Data plane software 


RTU 


Control Plane Assets 
Network Operating 
Systems 


Cryptographic 
Components 
Control plane software 


Application Plane 
Assets 
SDN Applications 


Hardware networking device that allows other Wi-Fi devices to connect to a wired 
network. EPES devices may communicate over wireless networks. 

Services which are offered to the entities of EPES (personnel, stakeholders, etc.), 
such as Mail, Terminal, Print, Authentication, File, Network, Name, Address 
Services. Those services are usually supported by general purpose servers and 
systems. 

Operating system (OS) is a software which acts as an interface between the end 
user and a computer hardware. EPES devices may have different OSs, which in turn 
may have different vulnerabilities. 

The EPES ecosystem can be based on a plethora of applications. In the context of 
the asset documentation process in this deliverable we use this generic term to 
refer to any application which cannot specifically be assigned to an energy-specific 
application. 

A network security system that monitors and controls incoming and outgoing 
network traffic based on predetermined security rules. A firewall typically 
establishes a barrier between a trusted internal network and untrusted external 
networks. 

Network server that automatically provides and assigns IP addresses, default 
gateways and other network parameters to client devices. 

Server that responds to authentication requests and verifies users on computer 
networks. DC is responsible for controlling host access to domain resources. It 
authenticates users, stores user account information and enforces security policy 
for a domain. Domains are a hierarchical way of organizing users and computers 
that work together on the same network. 

Network components that can be found in legacy ICT topologies, such as Routers, 
Switches, Gateways, Workstations, Servers (Web, Mail, Authentication, Business). 
This asset refers to any human in the SDN-microSENSE infrastructure from system 
and network administrators to simple end users. 


Assets related to the SDN field 


In the context of an SDN the behaviour of network devices and flow control is 
handled by software that operates independently from network hardware. SDN - 
routers, -gateways, -switches are programmable network components that can be 
found in the SDN-microSENSE architecture. 

The software component that realizes the northbound API of the network 
elements. 


RTUs able to operate in the context of Software Defined Networks. They can 
communicate via RTU controllers. 

SDN Controller for managing SDN-enabled RTUs to operate in the context of SDN- 
microSENSE project. 

Software used for supporting and managing the programmable network 
components in the data plane. 


Assets that realize the control plane for a software-defined network (SDN), 
managing network components, such as switches and links, and running software 
programs controlling the creation and destruction of network flows and paths. (e.g. 
OpenDayLight, ONOS, etc.) 

Provide encryption to the communications that pass through the SDN stack, among 
the assets of the Application, Control and Data planes. 

Software used for supporting and managing the programmable network services in 
the control plane. 


Applications that manage specific operations of the complex SDN topology such as, 
Network Visualization, Service Provisioning, Network Management, load balancing 
applications. 
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Table 13: Assets of the Electrical Power and Energy System ecosystem in the context of SDN-microSENSE 


AST-43 SDN user 
| Threat type Threat 
Nefarious Manipulation of 
Activity/Abuse network 
configuration / Data 
forging 


Software/firmware 
exploits 


Denial of Service 


(DoS) 


Remote SDN 
application 


exploitation 


Remote 
exploitation 


access 


© SDN microSENSE consortium 
Public document 


CAPEC 
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CAPEC-113: API Manipulation 

CAPEC-148: Content Spoofing 

CAPEC-153: Input Data Manipulation 
CAPEC-141: Cache Poisoning 

CAPEC-166: Force the System to Reset Values 
CAPEC-165: File Manipulation 

CAPEC-176: 
Manipulation 
CAPEC-438: Modification During Manufacture 
CAPEC-439: Manipulation During Distribution 
CAPEC-137: Parameter Injection 

CAPEC-548: Contaminate Resource 
CAPEC-137: Parameter Injection 

CAPEC-113: API Manipulation 

CAPEC-184: Software Integrity Attack 
CAPEC-165: File Manipulation 
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CAPEC-137: Parameter Injection 

CAPEC-175: Code Inclusion 

CAPEC-175: Code Inclusion 


CAPEC-125: Flooding 

CAPEC-272: Protocol Manipulation 
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CAPEC-130: Excessive Allocation 
CAPEC-624: Fault Injection 
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Control Security Levels 
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CAPEC-225: Subvert Access Control 
CAPEC-114: Authentication Abuse 
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CAPEC-225: Subvert Access Control 
CAPEC-151: Identity Spoofing 
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This asset refers to any User that is using equipment attached to the Data plane of 


Assets 
AST-[CP,DP, 
AP, 29, 30, 31, 
32, 25, 26] 


Virtually all 
cyber-enabled 
assets are 
exposed to this 
threat. Special 
focus on APIs, 


SDN assets, 
and 
services/applic 
ations with 
large 
codebase. 

Any asset that 
exposes a 
network 


commutation 
port can be 
targeted by 


this threat. 
Special focus 
on AST-[DP, 


CP, AP, 32, 30, 
26, 25, 01-13, 
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AST-AP 


Any cyber- 
enabled asset 
that exposes a 
remote access 
service visible 
either inside or 
outside of the 
internal 

network zone 
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CAPEC-21: Exploitation of Trusted Credentials 
CAPEC-115: Authentication Bypass 

CAPEC-122: Privilege Abuse 

CAPEC-233: Privilege Escalation 


CAPEC-480: Escaping Virtualization 
CAPEC-189: Black Box Reverse Engineering 


CAPEC-151: Identity Spoofing 
CAPEC-473: Signature Spoof 
CAPEC-21: Exploitation of Trusted Credentials 


CAPEC-403: Social Engineering 

CAPEC-416: Manipulate Human Behaviour 
CAPEC-185: Malicious Software Download 
CAPEC-23: File Content Injection 

CAPEC-41: Using Meta-characters in E-mail Headers 
to Inject Malicious Payloads 

CAPEC-185: Malicious Software Download 
CAPEC-187: Malicious Automated Software Update 
CAPEC-17: Using Malicious Files 

CAPEC-636: Hiding Malicious Data or Code within 
Files 

CAPEC-523: Malicious Software Implanted 
CAPEC-542: Targeted Malware 

CAPEC-17: Using Malicious Files 

CAPEC-442: Infected Software 

CAPEC-118: Collect and Analyse Information 
CAPEC-152: Inject Unexpected Items 
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can be 
affected. 
Particular 
focus on AST- 
[13, 15, 18, 26, 
28, AP] 
AST-[DP, CP, 
AP] 

Any cyber- 
enabled assets 
which includes 
a software 
stack could be 
affected. 
Among other, 
AST-[10, 24, 27 
28, 31, 42, 24, 
22] 


Several assets 
can be 
affected by 
unauthorised 
access. AST- 
[DP, CP, AP, 
29, 31, 24, 27, 
13, 33, 42, 53] 
AST-[DP, CP, 
AP, 32, 24, 28, 
27] 

Any asset 
which engages 
an 
authentication 
process for 
granting 
access can be 
affected. AST- 
[DP, CP, AP, 
13, 22, 23, 24, 
26-29, 31] 
AST-[33, 43] 


This threat 
implies the 
unauthorised 
access of 
assets using 
various 
combinations 
of attacks 
(malware, 
social engin., 
Identity theft, 
etc.). Virtually 
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any cyber- 
enabled asset 
can be 
affected. 
Exploit Protocol | CAPEC-272: Protocol Manipulation AST-IDP, 
vulnerabilities CAPEC-192: Protocol Analysis CP,AP, 01-20, 
CAPEC-210: Abuse Existing Functionality 25, 26, 28, 32) 
CAPEC-125: Flooding 
Eavesdropping/Interce Traffic diversion CAPEC-272: Protocol Manipulation AST-[DP, CP, 
ption/ Hijacking CAPEC-94: Man in the Middle Attack 32] 
CAPEC-272117Interception 
CAPEC-216: Communication Channel Manipulation 
CAPEC-272: Protocol Manipulation 
CAPEC-142: DNS Cache Poisoning 
Side channel attack CAPEC-189: Black Box Reverse Engineering AST-[DP, CP, 
CAPEC-622: Electromagnetic Side-Channel Attack 32] 
CAPEC-118: Collect and Analyse Information 
CAPEC-118: Fingerprinting 
Memory scraping CAPEC-545: Pull Data from System Resources AST-[AP, 26, 
CAPEC-546: Probe Application Memory 27, 28, 33] 
CAPEC-123: Buffer Manipulation 
CAPEC-540: Overread Buffers 
CAPEC-129: Pointer Manipulation 
CAPEC-456: Infected Memory 
Traffic sniffing CAPEC-158: Sniffing Network Traffic AST-[DP, CP, 
CAPEC-31: Accessing/Intercepting/Modifying HTTP | AP, 33] 
Man in the middle | Cookies AST-[DP, CP, 
(MITM) CAPEC-117: Interception AP, 03, 33] 
Interception of | CAPEC-651: Eavesdropping AST-[DP, CP, 
Information CAPEC-94: Man in the Middle Attack AP] 


Replay of messages 


CAPEC-60: Reusing Session IDs (aka Session Replay) 


Affects assets 


CAPEC-272: Protocol Manipulation that 
communicate 
using 
protocols 
without 
message 
replay 
protection. 

Network CAPEC-118: Collect and Analyse Information Virtually all 
Reconnaissance and | CAPEC-117: Interception cyber enabled 
Information CAPEC-169: Footprinting assets are 
gathering CAPEC-224: Fingerprinting prone to 

CAPEC-188: Reverse Engineering network 

CAPEC-192: Protocol Analysis reconnaissanc 
e threats. 


Table 14: Threats, attack patterns and affected assets for EPES 


It must be stated that the mapping of identified threats, attack patterns and assets are a subset of the 
possible combinations that can occur due to the constantly evolving threat landscape of EPES and the 
increased sophistication of cyber-attacks. However, Table 14 can be used as a concrete point of 
reference to steer S-RAF users to make informed decisions and gain a better understanding to the risk 
assessment process, and has been already used as a starting point for the demonstrators' scenarios 
planning. 


© SDN microSENSE consortium 
Public document 


Page | 79 


(x) SDN-uSense 
D3.5. 


Version 1.0 


5.3 S-RAF in the Context of Demonstrators 

Although the validation performed in the context of the demonstrators is part of the WP8 that is 
officially at M22 of the project, we consider that providing early access of S-RAF to the demonstrators 
would help eliminate issues and possible delays. For this purpose, S-RAF (without the integration to 
other external components) has been installed and provided by UBITECH in an online demonstration 
setup, in order to start working in the scope of demonstrators and collect initial feedback. The most 
important part of the work performed at this stage was to start populating the model of the pilot EPES, 
by collecting and defining in EPES assets (virtual appliances and services, protocols used, hardware or 
even people, collecting vulnerabilities and threats (e.g. a sec admin uses an easy password, that 
doesn’t comply to the rules). 


For this purpose, dedicated virtual workshops with each demonstrator were organized during July 
2020. Through this exercise we collected an initial set of assets used by the pilots (presented in Table 
15), and also agreed on some conventions (e.g. that protocols can be defined as a separate asset and 
the relation IS_USED_BY can be used by all assets using this protocol. 


Asset Business Details Run Asset Possible Threat Scenarios 
Type Value Privileges Dependencies 
Ubuntu Operati | Low | Ubuntu Loca INSTALLED O  CVE-2019- | - Flooding 
Server ng 16.04 LTS User, N: Server, 1000019 - Denial of Service 
system Loca IS USED BY: 
| Admin Administrator 
| Gateway Hardwar | Low | Cisco Loca | |S LOCATED | | CVE-2018- | - Flooding 
e Admin | N:At each 18068 - Denial of Service 
| | | | customers site | 
| Raspbian Operati Medium | Raspberry | Loca INSTALLED O  CVE-2018- | - Flooding 
| OS ng Pi 1 B+ Admin N: Gateway 18068 - Denial of Service 
| system | 
SDN- Hardwar High N/A Loca CONNECTED CVE-2019- | - Flooding 
Switch e Admin TO:SDN- 1010245 - Denial of Service 
enabled RTU, 
Communicatio 
| | n front-end 
SDN- Hardwar | Medium | N/A Local CONNECTED  CVE-2020- | - Denial of Service 
enabled e Admin TO: SDN- 15781 - Execute protocol 
RTU Switch commands 


- Gain information 
(eavesdropping) 
| | - Message reply 


LCU Hardwar Medium | Local Local | CONNECTED. N/A - MITM 
e control Admin TO: SDN- | - Denial of Service 
Units Switch - Spoofing 


| - Gain information 
| (eavesdropping) 
| - Message reply 


Electrical Hardwar | Medium | N/A Local CONNECTED N/A - Denial of Service 
Protection | e Admin TO:SDN- | - Execute commands 
S Switch, SDN- 
| | | | | enabled_RTU | | 
| IEC- | Protocol Low N/A N/A IS USED BY: N/A |- Eavesdropping to obtain 
60870-5- RTU, LCU, | parameters knowledge 
104 Electrical | 
| | | protections | 
| |EC-61850 | Protocol | Low | N/A N/A | IS USED BY: N/A IE Eavesdropping to obtain 
| RTU, LCU, | topology knowledge 
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Electrical 
protections 
Communi | Hardwar | High N/A Local CONNECTED N/A - Flooding 
cation e Admin TO:SDN- - Denial of Service 
Front-end Switch and - Manipulation of network 
Server configuration 
SCADA Softwar | Very Schneider | Local INSTALLED O | CVE-2020- | - Gain information 
e High Electric Admin N: Server 7522 - Scale privileges 
- Unauthorized access 
(eavesdropping/execute 
commands) 
- SQL injection 
- Receive data from 
spoofed devices 
Server Hardwar | Very Dell Local CONNECTED | CVE-2020- | - Exploit OS vulnerabilities 
e High Poweredg | User, TO: 5330 
e T110 Local Communicatio 
Admin n front-end 
Administr | Personn N/A N/A N/A N/A N/A - Unauthorized usage 


ator el 
Table 15: Representative assets of demonstrators, for S-RAF 


It has to be mentioned that this table includes only some representative data collected from all pilots 
and due to privacy reasons, this data is only examples and not real data. For the collection of this 
content all demonstrators have been provided with a dedicated spreadsheet that will be used further 
for the preparing the actual setup or work for WP8 needs. 


In addition to the definition of the EPES model, through the workshops with the demonstrators we 
examined the deployment options of SDN-microSENSE and the topologies to be used by the pilots. 
Again, although the demonstrators are still in planning phase, the initial list of assets can be defined in 
S-RAF, and the plans for deployment of SDN-microSENSE ( including S-RAF ) shall not create any issue, 
as S-RAF actually needs to communicate only with some of the platform components (XL-SIEM, AIDB, 
AIREC) and not the demonstrator assets. 
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6 Conclusions 


This document concluded the work performed in the scope of WP3 and had as result the creation of 
SDN-microSENSE Risk Assessment Framework (S-RAF). At first an analysis of existing tools for risk 
assessment are presented along with a wrap-up of the methodology of S-RAF that has been presented 
in deliverable D3.1 [2] with more details. The deliverable includes also the S-RAF architecture with the 
components and the corresponding interfaces, the implementation details as well as the installation 
and usage instructions. 


There are multiple risk assessment metrics that can be adopted from the literature, however, there is 
no specific framework that focuses on the EPES infrastructure. S-RAF is an innovative risk assessment 
solution targeted on EPES that considers the cumulative aspects of the needed to involve all 
stakeholders of the energy components. Currently, there are several tools in the market that quantify 
the risk, but without considering the aforementioned cumulative aspects. S-RAF cumulative risk 
assessment approach enables one to perceive the security state at the level of mission-critical assets 
that belong either in the same business workflow, or in the same physical (or virtual) networks. 


In addition, the main updates of S-RAF compared to the UBITECH's OLISTIC Enterprise Risk 
Management Suite, that it is based upon, are: 


Usage of updated model that supports EPES 

Collaborative Risk Assessment with the cumulative RA 

Connecting with AIDB for EPES asset retrieval 

Connection with eVul for automated analysis of vulnerabilities in the EPES environment 

Extending OLISTIC model and components for retrieving alerts from XL-SIEM 

Providing Incidents based on the Risk Assessment as output to SDN-SELF and ARIEC 

components of SDN-microSENSE 

7. Integrating Apache Kafka as message queue that can be used by both internal and external 
components 

8. Transforming data to MISP format 


gium Be © NA p 


The architecture of S-RAF is presented in this document, with focus on the presentation of the 
interdependencies and integration of the various components, while we also present some of the key 
aspects of the implementation of S-RAF. As this document helps the reader to have a first acquaintance 
with S-RAF, section 5 provides basic information about the installation and the usage of the platform. 
Although the evaluation of S-RAF as part of SDN-microSENSE will be performed in the scope of WP8, 
the preliminary usage of the S-RAF by the demonstrators has been executed to validate the suitability 
of the developed solution and methodology. Last but not least, the actual interfaces and integration 
points (especially the external component interfaces) could be updated in the context of WP7. 
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8 Annex | — Docker Compose for S-RAF installation 


version: '3' 
services: 
openvas: 
image: "mikesplain/openvas:9" 
ports: 
-"14434:443" 
- "19394:9390" 
volumes: 
- /media/your_path/sraf/openvas/data:/var/lib/openvas/mgr 
sraf: 
build: ./sraf 
ports: 
- "8091:8080" 
volumes: 
- Jsraf-init:/opt/sraf 
depends_on: 
- mysql.dev.sraf.io 
- mongo.dev.sraf.io 
- openvas 
environment: 
- sraf.management.vulnerability.auto=true 
- sraf.management.vulnerability.openvas.hostzopenvas 
- sraf.management.vulnerability.openvas.port=9390 
- sraf.management.vulnerability.openvas.userzyou name 
- sraf.management.vulnerability.openvas.pass-your pass 
- sraf.startup.inventory.asset.location=/opt/sraf/initial_ hosts 
restart: always 
mongo.dev.sraf.io: 
image: "mongo:3.4" 
volumes: 
- /media/your_path/sraf/mongodb:/data/db 
mysql.dev.sraf.io: 
build: ./db-init 
volumes: 
- /media/ your. path/sraf/mysql:/var/lib/mysql 
environment: 
- MYSQL_ROOT_PASSWORD= your pass 
- MYSQL_USER= you_name 
- MYSQL_PASSWORD= your pass 
- MYSQL_DATABASE=databasename 
z001: 
image: zookeeper:3.4.9 
hostname: zoo1 
ports: 
-"2181:2181" 
environment: 
ZOO MY ID: 1 
ZOO PORT: 2181 
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kafka1: 
image: confluentinc/cp-kafka:5.5.1 
hostname: kafka1 
ports: 
- "9092:9092" 
environment: 

KAFKA_ADVERTISED_LISTENERS: 
LISTENER_DOCKER_INTERNAL://kafka1:19092,LISTENER_DOCKER_EXTERNAL://S{DOCKER_HOST_| 
P:-127.0.0.1}:9092 

KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: 
LISTENER_DOCKER_INTERNAL:PLAINTEXT,LISTENER_DOCKER_EXTERNAL:PLAINTEXT 

KAFKA_INTER_BROKER_LISTENER_NAME: LISTENER_DOCKER_INTERNAL 

KAFKA ZOOKEEPER CONNECT: "z001:2181" 

KAFKA BROKER ID: 1 

KAFKA LOG4J LOGGERS: 

"kafka.controller=INFO,kafka.producer.async. DefaultEventHandler=INFO,state.change.logger=INF 
o" 
KAFKA OFFSETS TOPIC REPLICATION FACTOR: 1 
volumes: 
- ./zk-single-kafka-single/kafka1/data:/var/lib/kafka/data 
depends on: 
- 2001 
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9 Annex || —Unit Tests 


The unit test cases reported using a table describing the test, it’s preconditions, the input and the 
actual steps. SPEC ID refers to relevant specifications as have been defined in SDN-microSENSE D2.3 
deliverable. Finally, the results method tested and the actual test results are presented. For the 
implementation of the tests Junit framework? has been used. 


Test Case ID SRAF 01 Component Threat Identification 
Component 
Description  RabbitMQ consumer tester 
| SPEC ID SPEC-F3, SPEC-F4 | Priority | Medium 
Prepared — UBITECH Tested by UBITECH 
by | | 
Pre- e A RabbitMQ available 


condition(s) e atos.exchange.alarms.sdnmsense.cis available on RabbidMQ 


e Credentials properly configured on Threat Identification Component 


Test steps 

1 Read queue with input 
2 Read empty queue 
Input data — N/A 


Result . Retrieved and printed the Json Object of the Event (see CIS-RAF interface example) 
Test Case | Achieved, with test RabbitMQ setup 
| Result 
Test Case ID SRAF 02 Component Assets Identification 
Component 
Description Get assets from AIDB tester m m 
SPEC ID SPEC-F7 | Priority Medium 
Prepared UBITECH | Tested by UBITECH 
by | 
Pre- e AIDB installed and populated with test data 
| condition(s) e Credentials properly configured on Threat Identification Component 
Test steps 
1 Rest call to /assets_inventory_query 
2 Parse results 
3 Store to MongoDB 


Input data N/A 


Result | Assert proper storage of data to the database (based on the response of Mongo) 
Test Case Achieved with dummy REST call responses based on documentation, to be fully 
_ Result tested in integrated version of the platform 


Test Case ID SRAF 03 Component Assets Identification 


Component 
Description Get topology from AIDB tester 
| SPEC ID SPEC-F7 Priority | Medium 


2 https://junit.org/ 
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Prepared  UBITECH . Tested by | UBITECH 
by | || | 
Pre- e AIDB installed and populated with test data 


| condition(s) | e AIDB Credentials properly configured on Threat Identification Component 
| Test steps 

1 | Rest call to /topology query 

2 Parse results 


3 | Store to MongoDB 
4 | Store to Neo4J 
Input data — N/A 


Result Assert proper storage of data to the database (based on the response of Mongo and 
Neo4J) 
Test Case Achieved with dummy REST call responses based on documentation, to be fully 
| Result tested in integrated version of the platform 
Test Case ID SRAF 04 Component S-RAF Impact Analysis 
Component 
| Description Get Vulnerabilities for asset tester | 
SPECID  SPEC-F4 | Priority | Medium | 
Prepared  UBITECH | Tested by | UBITECH 
by | | 


Pre- e eVul containers running 
condition(s) | e Vulnerabilities available from eVul 
| e Valid assetID 
e eVul connection configured on Impact Identification Component 


Test steps 
1 REST call to eVul assetinfo method 
2 Parse results 


| 3 | Store to MySql 


Input data  assetlD 


| Result _ Assert proper storage of data to the database 
Test Case Achieved 
Result 


Test Case ID SRAF 05 Component S-RAF Impact Analysis 


Component 


Description Attack Path retrieval tester 


SPEC ID SPEC-F4 = Priority | Medium 
Prepared  UBITECH | Tested by | UBITECH 
by | | 
Pre- e Assets and their connection retrieved from AIDB 
condition(s) | e Asset topology stored in the Asset Identification Component databases 
| e Risk assessment Object and corresponding ID must be created 
Test steps mE 
1 | Call discoverattackpaths REST call with defined ID 
[2 Retrieve results 


"3 | Assert results (based on predefined ID and topology) 
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Input data | Risk assessment id 


Result _ Retrieved and printed the Json Object of the attack path 
Test Case Achieved 
Result 


Test Case ID SRAF_06 Component S-RAF Risk Level 


Assessment 
Component 


Description Cumulative Risk Assessment results tester 


SPEC ID SPEC-F4 | Priority | Medium 

Prepared | UBITECH Tested by UBITECH 

by | tans 

Pre- e Created Risk Assessment Object (containing at least 3 assets, threats, 
condition(s) vulnerabilities), with riskassessmentService.create 


e Create BusinessParter object (representing organization) 
e All components of S-RAF up and running 


Test steps 
1 Execute riskassessmentService. countRiskassessmentsForBusinesspartner 
2 Write result 
3 Assess the test by examining if valind Long number is provided 
Input data N/A 
Result Valid Long number 
Test Case | Achieved 
Result 


Test Case ID SRAF 07 Component S-RAF Risk Level 


Assessment 
Component 


Description Kafka exporter for ADAE 


SPEC ID SPEC-F4, SPEC-F6 Priority Medium 
Prepared UBITECH Tested by UBITECH 
by 

Pre- e Kafka up and running, topic sraf.out.adae has been created 
condition(s) e XL-SIEM input provided 


e Vulnerabilities retrieved from eVul 
e Generation of assessment output for ADEA 


Test steps 
1 Connect to Kafka 
2 Write result 


3 Read result to assess the test 
Input data N/A | 
Result Retrieved and printed the Json Object of the assessment results that were published 
in step 2. 
Test Case Achieved 
Result | 
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Test Case ID SRAF 08 Component S-RAF Risk Level 


Assessment 
Component 


Description  MISP transformation 


SPEC ID N/A | Priority | Medium 
Prepared | UBITECH Tested by UBITECH 
by | 

Pre- e Risk Assessment Results available 

condition(s) e MISP format of the result available for assertion 

Test steps 


1 Prepare String input 
2 Execute Utli.transalateToMisp() 


3 Assert results 

Input data | e Risk Assessment Result including vulnerabilities provided as text 
Result Assertion of output text 

Test Case Achieved 

Result 


Test Case ID SRAF 09 Component S-RAF Risk Level 


Assessment 
Component 


Description Kafka exporter for ARIEC 


SPEC ID SPEC-F4, SPEC-F5 | Priority Medium 
Prepared | UBITECH Tested by UBITECH 
by | 

Pre- e Kafka up and running, topic sraf.out.ariec has been created 
condition(s) e XL-SIEM input provided 


e Vulnerabilities retrieved from eVul 
e Generation of assessment output with the MISP format agreed for ARIEC 


Test steps 
1 Connect to Kafka 
2 Write result 


3 Read result to assess the test 
Input data N/A 
Result Retrieved and printed the Json Object of the assessment results that were published 
in step 2. 
Test Case Achieved 
Result 
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